On Sat, Jan 3, 2009 at 4:43 AM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > 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.
Ah, I wasn't sure that this was active, cool. > > 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 :-) Ah yes, this is definitely a problem. See, I had to be able to import based on a string (database backend), and I was having problems doing so without an absolute import. I defaulted to this, and didn't think much of it. I'll get on this. > >> 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. > Yes, my solution to that, although undocumented I realize, is to allow migrations to also be completely sql. So they would live right next to regular migrations, but have a .sql on them. I was also going to make an option to ./mananage.py migrate that is --sql, so it would build the migration for you just the same, but as sql. >> * 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. > Tested as in I've got a test suite and I've run it for each backend, BUT, my test suite is not very large yet, and is missing a lot of edge cases, which is what I'm primarily working on right now. > 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. I'll get on that. > > Best of luck with Migratory - this isn't a trivial task, and what you > have shown so far is quite impressive. > Thanks Russ! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
