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
