I think versioning databases is best solved in terms of database refactorings. For this there should be a small toolkit providing the building blocks to implement refactoring scripts. The building blocks would implement the part that is always the same and provide hooks for the part that differ. For example AddColumn refactoring does the adding of the column, but provides a way to have a function that calculates the default value for the column.
To make creating the refactoring scripts easier there would be AutoCode like tool that diffs two schemas, infers the simple refactorings and provides a template refactoring script to take the database from version A to version B that can then be customized as necessary. To manage the refactorings there would need to be a tool that given an existing version of the database and a target version finds the a path through refactoring scripts that would do the migration. The existing version can possibly automatically read from a special table in the database or maybe even automatically detected by comparing the schema with known versions. The target version can be read from the installed version of the schema description or again by comparing it against known versions. I am currently already using this kind of scheme, though the first two parts are basically missing - I'm using plain and simple python scripts. This is something that I am interested in working on, but I want to get the generic clustering framework working before I move on. Though if anyone else wants to take this one on, they're welcome, I'll be happy to join forces later when I have time. Ants --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" 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/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
