Thanks Ned, that's certainly something I want to bear in mind. At the moment the dbmigration code only uses sql migrations, but the way the migrator is put together will allow me to build support for migrations written in python quite easily.
Before I release the code, I want to make the migrator call 'install' from django.core.management if it doesn't find a migration module for an app. Also, as this is being done as part of a work project, I have to get permission to release the code from my employer, but this should not be a problem. Hopefully I'll have something released by the end of today, if not, by the end of Monday. Thanks for your comments! Mike On 4/20/2007, "Ned Batchelder" <[EMAIL PROTECTED]> wrote: > >Just one comment on this: At Tabblo, we've found it very useful to have >not only SQL migrations, but Python migrations as well, because database >migrations involve not just schema changes, but also data changes. >While SQL can be used to update the data, it can be much easier to do it >with Python. > >So we've built a similar migration scheme, except the migrations are >Python functions. The vast majority of the migrations (we're up to >number 191) simply execute SQL statements, but the few times we've >wanted the help of the model classes, it has been very helpful to have >the full power of Python available to us. > >--Ned. > >Mike H wrote: >> Hi all, >> >> I've been working on a tool to give me an automated way of altering the >> schemas on servers I deploy my django applications to. I know about the >> schema-evolution branch, but the current approach of that isn't >> completely automated and the work seems to have stopped on it. >> >> The approach I have taken is very simple. Inside each application >> installed in your project, you create a migrations module. Inside there >> is a list of migrations that need to be applied and an sql directory >> that contains the actual migrations themselves. >> >> For example : >> >> cms/ >> migrations/ >> migrator.py -- holds the list of migrations to run, in the order >> to run them >> sql/ >> InstallInitialStructure.sql >> AddNewAttributeColumn.sql >> ... etc. ... >> >> So with this approach you would create the initial structure sql file >> using the django sql generation, then you would have to produce sql >> files for each addition / deletion / merge you need to make. >> >> The sql directory can have subdirectories named the same as your database >> engine if you need an engine specific sql file. >> >> All that is needed is to copy a migrate.py script into the root of your >> project and run 'python migrate.py' - any migrations on any of the >> installed applications that have not been run would automatically get >> run and a log kept so that migrations do not run twice. >> >> Does this sound useful to anyone who is doing automated deployments? >> >> Mike >> >> > >> >> >> >> >> > >-- >Ned Batchelder, http://nedbatchelder.com > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" 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/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
