Michael Monnerie wrote: > Also, have a single upgrade script to upgrade any schema version to the > newest would be very appreciated. So people who have an early 2.2 would > also get the newset indices etc. A table "version" would be nice to have > where a single "dbmail-schema" value is included. Would be good for > support also. > > mfg zmi >
I'm not sure where we sit on a table containing configuration options. If we did have a dbmail_config table, then I would like to see an schema_version entry that would be an incrementing number. As changes are pushed out, the update_schema.sql script would read start the process where the version last left off. I'm not sure if a per user script to move messages is the best approach. Probably just need to add it to dbmail-util to move them from the old structure to the new one. We don't even need to change the phymessage_id, just insert the mimeparts, then the partslist rows. Once those are there, the physmessage_id rows can be deleted from the messageblks. Since we are now using libzdb, we really only need to provide each program with the connection string. It would dictate what database type, host, user/pass, db name, etc. That would make our dbmail.conf real simple with just a connection string in it. Everything else would be read from dbmail_config. If we add a configuration version row in there that is also incrementing, then the daemons could be told that a new configuration is in place and they should restart to catch the change or change what is required. I'll look into making dbmail-util migrate the data, then we can think about a config table. I would love to have a config table there in 2.4.0 and a schema version saved as well so updating can be much easier and less room for error. -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
