"Carlos Ribeiro" <[EMAIL PROTECTED]> writes: > I may be wrong, but IMHO database versioning has nothing to do with software > versioning. My up-to-date 005 module may be used at any time with a 004 > database, or even with a 002... or 001. That's life. A database versioning &
That's not always true. Sometimes the version of your software changed just because the database had to change. Or your database changed because your software changed. But I agree that both are different things. One thing that is going towards this direction is SQLObject's sqlobject-admin. Anyway, to make things work you have to make a requisite of having your database in version X for your software version Y. Version X-1 might not have some needed column / table and it will break your software. > migration toolkit would help to deploy newer versions; when it detects a > previous version of the database, the migration kit would be automatically > invoked to bring the database up to date. This is an invaluable tool to use > when you're trying to keep your production version in sync with your daily > builds. This is also not that simple. Specially when you add new "not null" columns to some table. If it is a human being, he can provide some default value or let the column temporarily without the restriction and later, when all records are updated, he can add this restriction back. Managing software and managing databases are very different things and this should be taken into account when doing this. What I do here is using the "history" feature of SQLObject to record how are things at some given time. Then, I modify my model, generate the new SQL and create "maintenance routines" that update the database. These routines are just SQL commands to modify the database structure. I add those to my VCS and then I know that I have to apply those updates to my database. I even have a routine for doing that, in the order that they need to be applied (I may have made lots of changes in the last 3 months before updating some client's installation). Having said that, there's a tool named "sqldiff" (http://phpsqldiff.sourceforge.net/) that does something like that. There are other tools that work with lots of database servers. I remember seeing one that converted your DB structure to a XML file, diffed the resulting XMLs and then constructed a set of SQL statements to make one database equal to the other. -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
