On 1/18/06, Jeffrey E. Forcier <[EMAIL PROTECTED]> wrote: > > I do something similar to both Eric and Maniac, e.g. I create SQL > language files which contain ALTER TABLE and similar statements, and > apply those to a 'base' database to transform it into the most recent > version without losing data. I haven't automated it yet like Eric > has, but it won't be too difficult to accomplish when I want to.
What we're all doing is creating our own flavors of version control with migration scripts. ;-) I've often wondered why databases are so special; app deployment requires migration of existing data, too. We just don't try to build an installer every time we make an app. It seems to me that a DB Version could be a django sys table attribute, and that the model could have that version number. If out of sync, django could give an informative error: "Err: poll model version 3 running against DB version 1". And providing some "convention over configuration", there could be a model-migration directory with file names like migrate_1_to_2.sql I haven't suggested this before because I wasn't prepared to implement it, but the discussion made the opportunity too ripe. ;-)
