Nice work Russ! Got to love when something goes from "nice to have" to "done".
Anssi, I don't think I understand your use case. Even if an unmanaged model doesn't have a literal table behind it, it needs something which at least resembles a table (i.e. a view) to query against. Otherwise the ORM will generate errors regardless of the behavior of .raw(). To answer your question, raw() determines what fields are populated by the names of the columns returned by the database cursor. Accordingly, if you want to pull different fields using different queries, you probably do so using subqueries in one big SQL statement. As long as the field names returned by the query match the field names in the model or you provide a translations parameter to describe which query fields go to which model fields it should work. As far as allowing users to define raw queries for each field to allow them to be deferred, this is way outside the scope of this patch. The goal of .raw() was to provide some relatively simple syntactic sugar to make a common class of raw queries easier. It was not intended to completely replace all possible use cases for doing raw queries using a cursor. ____________________________ Sean O'Connor http://seanoc.com On Wed, Dec 16, 2009 at 9:19 AM, Anssi Kaariainen <[email protected]>wrote: > > > On Dec 16, 2:51 pm, Russell Keith-Magee <[email protected]> > wrote: > > On Wed, Dec 16, 2009 at 7:56 PM, Jeremy Dunck <[email protected]> wrote: > > > On Dec 15, 2009, at 11:16 PM, "Sean O'Connor" > > > <[email protected]> wrote: > > > > >> 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. > > > > > I like the idea of the deferred fields, but if we don't implement it > > > now, people may come to rely on the AttributeError so that we can't > > > add deferred later. Perhaps a note in the docs stating our intent to > > > add deferreds would suffice? > > > > No need for workaround docs - I've just uploaded an RC3 patch that > > implements deferred fields. > > > > The one gotcha on this patch is that it now requires that you request > > the primary key when you retrieve an object. That is, you can't just > > run:: > > > > Author.objects.raw('SELECT firstname, lastname FROM author') > > > > You must now include the pk: > > > > Author.objects.raw('SELECT id, firstname, lastname FROM author') > > > > If you don't, you get an exception. Unfortunately, it's an exception > > after the SQL has been executed, but that's the only way to know > > exactly which columns have been requested. > > > > This is slightly more restrictive than Jacob's RC2 patch - but I think > > the RC3 behaviour is preferable. The primary key value is a fairly > > essential part of the Django infrastructure. In RC2, if you retrieved > > an Author with firstname and lastname, then saved the object, you > > would get a new object in the database. RC3 avoids this because the > > deferred object has the right primary key. > > > > If the price of avoiding surprises like this is forcing the PK to be > > retrieved, I think it's a price worth paying. If you really can't > > afford to have the PK retrieved, then I'd argue you aren't retrieving > > a Django object; you can still call on raw SQL cursors to accommodate > > those use cases. > > One use case where deferred fields aren't so nice is when creating > models which don't have any backing tables in the db. That is, models > with managed = False. These models would be the Django equivalent of > views. In these cases trying to access the field, even for testing if > it is None, would result in db query and an exception. And probably in > aborted transaction, too. > > Using raw() as a way to perform view operations (complex joins etc.) > is the first use case I though of when I saw this. Anyways, using > default or None as a value isn't good either. How do you know if you > got that from the DB or not? A nice way to test which fields the model > were populated and marking the non-populated fields as deferred would > be optimal in my opinion. One use case where you don't necessary know > which fields are populated and which ones aren't is when you have > multiple raw() queries defined populating different fields of the > model. > > Anssi Kaariainen > > -- > > 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.
