FYI, this is very similar to the approach we've used since 2001 when doing schema updates of our product, DynaCenter (http:// www.racemi.com). It has nothing to do with Django but the problem domain is the same.
Our scripts are called "alter scripts" instead of migrators. We also added version information in the script names to allow the main migrator script, which we call 'alterdb', to load the scripts in a configurable order. The driver loads the alter scripts, which implement a simple two method interface, test and apply, allowing the driver to call apply only if the test() method returns True. The alter script can then check the schema in the test() method to see whether, for example, a particular column is there or not, and then, if needed, the apply method can create the column and possibly move data from one place to another. Of course, as time went by, we added more utlitiy methods to the "alter scripts" base classes such as methods to create columns, test presence of a table, create indexes, etc. We can mix SQL and python in this context as needed. This method has worked very nicely for us through the years. On Apr 19, 10:43 am, "Mike H" <[EMAIL PROTECTED]> 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
