On Tue, Sep 29, 2009 at 9:29 AM, Alex Gaynor <alex.gay...@gmail.com> wrote: > > On Mon, Sep 28, 2009 at 9:24 PM, SeanOC <sean.b.ocon...@gmail.com> wrote: >> >> Hello All, >> >> During the Djangocon sprints I started to work on a patch which would >> add a nicer interface for dealing with raw SQL queries. While there I >> talked to RKM about where it should fit into the ORM API and where in >> the code base should live. I've finally gotten around to finishing >> the code I wrote during the sprint and have posted a patch to the >> related ticket (http://code.djangoproject.com/ticket/11863). You can >> also get the code from http://github.com/SeanOC/django. >> >> So far the patch is functional and has some basic unit tests but it is >> not documented. I'll be working on the documentation this week. In >> the mean time, the unit tests are probably the best place too look for >> how to use the code. >> >> If anybody would like to look over the code and provide some feedback >> it would be greatly appreciated. >> >> Thanks! >> >> -SeanOC >> > >> > > So my question, and this is something I've been thinking about a lot > of the proposals lately is: why should this be in Django itself. This > looks to me like something that would work perfectly well outside of > Django itself, indeed it's just a custom manager.
Yes, this *could* be done entirely externally. However, I think it is a manifestation of a pattern that we actively encourage, so therefore we should provide nice API support for it. I've lost count of the number of times I've said "ORM != SQL, so just use a cursor and write raw SQL". However, "write raw SQL" isn't always trivial, since you don't get back ORM objects. If you want ORM objects, you have to: (1) know about the trick of instantiating an object with the unrolled list version of a cursor, and (2) ensure that you've got all your columns specified in the right order. We can fix (1) with some documentation, but (2) is one of those nasty implementation details that you don't know you've got right until everything blows up in your face. There's also an edge case where two versions of a table might end up with different column orders due to applying different migration strategies on each version. If this happens, then the cursor approach fails because there is no consistent column order. If we can provide API-level support to make it easier to write custom SQL, I think we should do so. 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 -~----------~----~----~----~------~----~------~--~---
