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 
tonight.

> 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
> addresses/users.

Exactly.

> 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 
changes.

> --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 
performance.

> 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
> already.

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 
existance).

> 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 
the master).

> 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.

Cheers,
-- 
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

Reply via email to