[EMAIL PROTECTED] wrote: > we've put such a notion in our db, so the db knows what model-version > it matches. Then, at start, depending on the versions one can decide > which migration script to execute (if the db should be made to match > the py-model), or which feautures to drop (if py-model should follow > the db). btw there should be some tricky strategy as of what to > call "db-model-version" and when that "version" really changes.
This is getting into a big area: the problem of version control/configuration management for databases. When maintaining a database for a web site, I wound up doing that via a set of scripts (which were put in version control) and procedures to update the production database schema, followed by migration of the "user data" where necessary. It wasn't clean or pretty, but I had it down to a reliable, repeatable process. For my current job, I'm maintaining a DB-based application that we sell to customers, so not only do I have to version the database, I have to produce scripts to allow customers' incarnations of the DB to be upgraded as well, again respecting the user data (and site-specific changes that they make). I'd really like to introduce a genuine concept of "version stamping" and have a way to "evaluate" a customer's DB to determine what needs to be done when I've got a major schema change to apply. I'm just getting started with SA, but I like the ORM level, and I'm hoping that it will help in this area. (Just having a realized "object-level schema" should be a big step forward.) -- Don Dwiggins Advanced Publishing Technology --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
