Big thanks Jacob for picking up my slack and putting the finishing touches on the patch and writing the docs. Work got crazy and I dropped the ball. Definitely happy that the work will get completed and put into trunk regardless.
In regard to the deferred fields option, I'll let Jacob speak for his view but I've approached such functionality as "nice to have" for the patch since its not critical to the patch being useful. Personally I haven't had the time to figure it out and implement it so my original patch didn't include it. For the multidb approach I'd lean towards the kwargs approach. Right now the .raw() code is fairly well insulated from the bulk of the ORM and visa versa. This keeps the raw() code pretty simple and minimizes the opportunities for introducing new bugs in the ORM. As far as putting raw() on querysets I'd be pretty against it as well. It strikes me in a lot of ways as mutli-table inheritance does. People are really going to want it, until they try and use it in the real world, and realize that it was a really bad idea. While I'm sure Russ or some others around here could work some awesome magic and get it working after a fashion, I don't think it will ever work the way a new user will expect. What does performing a raw query on a queryset even mean? In the end I think adding .raw() to queryset would lead to a much more complicated implementation and more confusion for users. ____________________________ Sean O'Connor http://seanoc.com On Tue, Dec 15, 2009 at 8:24 PM, Russell Keith-Magee <[email protected] > wrote: > On Wed, Dec 16, 2009 at 6:15 AM, Jacob Kaplan-Moss <[email protected]> > wrote: > > Hey folks -- > > > > Forgot to mention it during the sprint this weekend, but I've pushed a > > RC patch to #11863, Model.objects.raw(). If anyone's got any feedback, > > let it fly. Otherwise, I'll be checking this in in a couple-three days > > or so. > > Hi Jacob, > > A couple of quick notes on the RC2 patch: > > * If you have an incomplete selection of fields, the patch currently > marks those fields as None/default values. Couldn't (Shouldn't?) they > be marked as deferred fields? > > * Looking slightly forward - what's the integration point for > multidb? One option is to put a using argument on raw:: > > Person.objects.raw('SELECT ...", using='other') > > It would be nice to allow .using(), but while it is easy to allow:: > > Person.objects.raw('SELECT ...").using('other') > > it isn't so easy to allow:: > > Person.objects.using('other').raw('SELECT ...") > > We could jump through some hoops to put raw() on queryset, but raise > exceptions under most uses (i.e., if you've performed any query > modifying operation). However, this is a lot of hoops just to allow an > edge case API use. > > Obviously, multidb isn't in scope for this patch, but given the > obvious overlap, I thought I'd ask for opinions. > > Other than that, RC2 looks good to me. > > Russ %-) > > -- > > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<django-developers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" 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-developers?hl=en.
