On Sat, Jan 3, 2009 at 5:25 PM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > > On Sun, Jan 4, 2009 at 4:28 AM, Brantley Harris <deadwis...@gmail.com> wrote: >> 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. > > It doesn't sound like this should be as big a problem as you describe. > Also, keep in mind that database backends are allowed to live outside > django.db.backends - this is how we support external development of > backends. The backend import code from Evolution and from Django > itself should give you a few pointers on how to do this in a location > independent fashion. >
It's not a big problem, I'll figure it out. I took the easy way out, and will be punished :) >>> 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. > > The 'put the sql in a file' option is the same thing that Evolution > does. Better still would be to be able to 'compile' a python migration > into SQL - this would keep all the auditing DB admins happy - but I > acknowledge that this is a pretty hard ask. Not so hard, there is actually an undocumented command "python manage.py migratesql" that will pop out the sql that the next migration would do. It's not documented so far because if you use it on an edited migration that has custom api commands, they will still run when popping out the sql, which is a problem. Theoretically if I could put it into an uncommitted transaction, everything would work out, but I'm not sure if that works for each backend? So I have to figure that one out. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
