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]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
