On Wednesday 20 July 2005 01:46, Rick Widmer wrote:
> First, this is getting pretty far off the topic for this list, it
> might be good to move to [EMAIL PROTECTED]
> the official list for vpopmail development.
Thank you, I had no idea that list existed! I will join it later
> One thing you need to worry about, there are currently two
> strategies vpopmail users for storing domains. One has one table
> per domain, the other puts all domains in a single file. The
> first would be pretty hard to do with a .sql file because you
> don't know the table name until you create a domain.
One table per domain simply doesn't sense in a relational database.
I can see how it might for flat files though I don't know how large
CDB files perform.
> I was hopeful we could eliminate the one table per domain setup,
> but just found out Qmail Rocks suggest that as the standard
> setup. :(
Assuming you're talking about the default CDB support, this is also
the way that many packagers have it set up by default too,
including Gentoo and Red Hat.
> I would like to see a third strategy with a more relational
> database. For example there would be a table for domains with all
> domain related data (limits) in it, and another table for
> I very much like the vpopmail way of compiling settings into the
> program. It is a little more hassle to change your
> configuration, but it really files on a heavily loaded server.
It's however impossible for distributors to manage.
> I don't think you will find much support for you changes if you
> are too radical. What ever you do will need to be reasonably
> compatible with MySQL and the other databases vpopmail supports.
I disagree strongly with this. The postgresql driver need not
suffer simply because mysql has severe limitations. MySQL is not
up to par with other database platforms in that it does not support
views, stored procedures, namespaces, triggers, or many other
things that you will find present in nearly every other relational
database platform, including PostgreSQL, IBM DB2, Oracle, Microsoft
SQL, Sybase, the list goes on and on... Until recently, MySQL
didn't even support nested queries.
Restricting things to the least common denominator is a big mistake.
In contrast, some queries which fly on MySQL (i.e. selects with
enourmous IN (...) clauses are sluggish on PostgreSQL, and other
queries which fly on PostgreSQL are sluggish or not supported on
MySQL. The best approach is to keep the modules separate as they
are now, and tune each as appropriate for that database platform.
The capabilities of each database are different, you can't just
swap one out for the other without anticipating a lot of required
> --enable-mysql-logging went away very recently. It is replaced
> with --enable-sql-logging, because we want all the database back
> ends to work the same way.
Okay, this makes sense. Logging to a database should be supported
on all database backends. However you may want to do it in
different ways, i.e. having a user_id column that references a
users table rather than a varchar/text column.
> For account management, you will definitely need to be able to
> insert delete and update records in various tables. Right now
> the table structure is kind of messy, but that is what the
> installed base is running with.
Compatibility functions can exist for the installed base, or they
can migrate to a newer recommendation. It just gets a bit tricky
because of the variety in what the installed base actually is.
> Personally, I wouldn't object to having all fields in the table,
> and the program can ignore those that are not needed. Again the
> key point will be backwards computability.
I think that the key point should be performance. It certainly will
be on my database. Compatibility functions should exist for
compatibility only - the older schema is not optimized for
efficiency. However for the PostgreSQL side of things, you can use
any backend structure you like without reconfiguring vpopmail,
because it can all be abstracted via stored procedures and views.
I have no intention of touching/changing the MySQL module - that is
best left for those familiar with MySQL's capabilities and
> I believe the database credentials have been moved to an external
> file for MySQL and Postgresql. It certainly has for MySQL, which
> suggests it should be added to Postgresql if it isn't there
It exists for MySQL, but does not exist for PostgreSQL (or at least
what PostgreSQL support does exist functions when it is not present
- I haven't dug through the code to see if it checks for the file's
> The missing link is lack of replication in Postgresql, I believe.
There are several replication engines for PostgreSQL, the best of
which in my opinion is Slony. Replication is not a strict
requirement for failover servers anyways. That's a detail that
vpopmail should not care about. The data may be replicated using
other methods (such as DRBD+heartbeat without changing the IP of
> Two words.... Backwards Compatibility! I'm pretty sure a
> radical change that can't be duplicated with the other databases
> will be rejected.
Well I'm not going to play the least common denominator game,
there's very good reasons why I don't use MySQL. I can work to
provide the best solution possible for PostgreSQL with support
backwards compatibility with old databases, without touching the
other backend modules.
There's simply no reason for the modules to be identical. Working
with MySQL versus working with CDB files is as different as working
with PostgreSQL versus working with MySQL. Trying to make a least
common denominator solution will simply not be efficient except
perhaps on one platform that the development is centered around.
Casey Allen Shobe | http://casey.shobe.info
[EMAIL PROTECTED] | cell 425-443-4653
AIM & Yahoo: SomeLinuxGuy | ICQ: 1494523
SeattleServer.com, Inc. | http://www.seattleserver.com