Am 19.06.2013 16:20, schrieb Harald Leithner: > A simple solution, as Harald mentioned, would be to check the database schema > on dbmail startup. > > Simple as a reference SQL file and a complete structure dump of the database > like: > > "for each table in database dbmail do" > "show create table" > dump it into memory > > compare this output with the reference sql file and die if it is not the > same. (Including useful output ;-)
+1 but *without* die, that may end in troubles which are not worth because not all differences are a real problem we have a "client_idnr" in "dbmail_users" which works with meta-tables and our backend :-) ___________________________________________ that is why it would make sense one last time make sure the schema including all fields and keys have the official values from Paul and after that he can version out each change which is needed predictable and to not play lottery do this not automatic and log only a warning that "dbmail-util" is hardly recommended to apply schema-changes they would be 100% predictable if this code is always maintained at the same time as changes are introduced and even revert of such changes would raise the schema-version which has as action the revert the only thing dbmail-util needs to know "from version 4 to 5 mysql needs these commmands and pgsql needs these commands" if they now add or remove fields, tables or keys does not matter, a change is a change
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
