On Sat, Jan 3, 2009 at 5:29 AM, Brantley Harris <deadwis...@gmail.com> wrote: > > Having not been content with the state of Django migrations systems, > I've created one of my own: > > http://www.bitbucket.org/DeadWisdom/migratory/
In the aftermath of DjangoCon [1], Simon Willison, Andrew Godwin and myself started the django-migrations SIG [2], with the aim of getting a migrations framework into the Django core that draws from the best parts of our three respective frameworks (dbmigrations, South and Django Evolution) [1] http://www.youtube.com/watch?v=VSq8m00p1FM [2] http://code.google.com/p/django-migrations-sig/ After some initial activity, there hasn't been much progress, mostly due to other development priorities in our busy lives (personally, this means aggregations and some other features for Django v1.1). However, I have high hopes that we can get discussions going to deliver something in the v1.2/1.3 timeframe. You clearly have some good ideas (and more importantly, some working code implementing those ideas) - I would encourage you to get involved with the SIG. Some quick notes regarding what I have seen so far: Firstly, your suggestion that people symlink into django.contrib is _really_ bad practice. There shouldn't be any need for your code to reside in django.contrib, and I'd like to discourage this as a practice before it takes hold as a defacto standard. If there is some technical reason why the django.contrib namespace is required, then raise that issue on the developers list and we can see what we can do to break that dependency. I can't think of anything that would cause such a dependency, but it's usually the things you don't consider that turn out to be problems :-) > The idea is a database migration system that: > * Doesn't make you use sql. This is an orm, we shouldn't have to use sql. I would agree that using SQL shouldn't be required, but the consensus of all the discussions that have taken place around 'the one true schema evolution framework' is that a raw SQL mode should be possible. This is for at least two reasons: 1) Satisfying DB Admins that want to manually audit any schema change. The bigger the company, the more likely a migration strategy will be required, and the more likely that DB admins will want to check everything you do. 2) Performance on very large databases. "for obj in Model.objects.all(): change(obj); obj.save()" is very Pythonic and very easy to read, but will not perform very well on large databases. Having an easy way to drop to raw SQL is essential for these cases. > * During the migration process, *allows you to use the state of > your previous models as if they were still there*. This is key, and is > not done anywhere else, as far as I know. This is very cool, and I like the way that this aspect is implemented (the stored snapshot files). I had considered solving this problem using some metamodel magic, but your approach is a lot more elegant. > Currently it's tested on mysql, postgresql_psycopg2, and sqlite3. Tested in what sense? - I've run it on my test project and it works? - I've got a test suite and I've run it for each backend? - I've got comprehensive test cases which pass for all backends? I have two reasons for asking: 1) Your test suite seems very small - especially considering the multitude of edge cases that need to be considered. The breadth of testing is one way to get indication of how robust the project is. 2) Ticket #7835 describes a feature that should hopefully make testing schema migration easier - I'd be interested in any feedback you might have on this ticket, and what features you would need to make testing Migratory easier. Best of luck with Migratory - this isn't a trivial task, and what you have shown so far is quite impressive. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
