Am 19.06.2013 16:00, schrieb Reindl Harald: > Am 19.06.2013 15:55, schrieb Paul J Stevens: >> On 06/19/2013 03:46 PM, Reindl Harald wrote: >> >>> what about having a meta-table which could be created at startup if >>> it does not exist containing the version of the sql-scheme by a >>> increasing number >> >>> if you make any change to the scheme raise the internal number, >>> select what is currently applied in the metatable and the needed >>> changes should be pretty clear i think >> >> Since MySQL schema changes are not atomic - you can't wrap them in a >> transaction - I don't see how that would provide more than cosmetic >> relief. It would be easiest to achieve though, I agree. And since all >> other backends do support atomic schema changes, it would help most users > > atomic or not - it would be better to apply a new field on a view > non-atomic than see no messages at all in random mail clients
the issue with none-atomic schema changes in MySQL could also be easily solved by having "dbmail-util --update-scheme" or whatever the switch is called * log a warning at startup if the scheme is outdated * recommend stop the dbmail-services and run "dbmail-util --update-scheme" * after that start the services again and all is fine for the start of such a feature we would need a recent list of all tables, fields, field-types and keys in a better readable format than a sql-dump so that we users have a way to make one last time sure our schemes are in a 100% predictable state inclduing also the exact names of keys to prevent later problems with "alter" statements as i had by dmail2->dbmail3 after this is done we could manually set the current schema-version in the new meta-table and from this moment on dbmail-util could work in a predictable way and with check if fields/keys exists before add or remove them this could get really stable by manually apply changes at development, revert them and change the version-value this could also be well tested and even get a autotest of dbmail-util ______________________________ i would the meta-table create as key/value thing dbmail_meta (setting, value) db_schema -> 3 ______________________________ so it could be as well used for other settings later
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
