Sorry, I misunderstood the original request. Yes, you're right Anssi and Adrian, finding them on demand is reasonable.
Alex On Thu, Apr 25, 2013 at 4:59 PM, Anssi Kääriäinen <anssi.kaariai...@thl.fi>wrote: > On 25 huhti, 20:08, Alex Gaynor <alex.gay...@gmail.com> wrote: > > This sounds like a reasonable request, I don't yet have an opinion on API > > or anything. One tiny thing I'd like to note though, "change > DeferredAttribute > > to find all *other* DeferredAttributes". I don't think `finding` is the > > right way to think about it, a `DeferredAttribute` with loadall semantics > > should know about the specific set of objects that came from the > queryset. > > Searching for deferred fields already happens in some places (at least > model.__init__ and model.save()). It would be possible to store the > set of deferred fields in model._state on load from DB, but why record > this information (with real possibility of messing it up if users do > something like direct __dict__ assignments after load from DB) when > there is a way to calculate the set of deferred fields on demand? One > possible reason is to avoid the expense of the calculation, but the > calculation costs very little compared to the DB query about to > happen. I actually tried to store the set of deferred fields per > instance when polishing the update_fields patch but the approach > turned out to be uglier at least for the update_fields case. > > Now, if there would be some way to avoid the dynamic model subclassing > used by deferred loading then storing the set of deferred fields per > instance would be more than welcome. One possibility might be defining > Model.__getattr__. If you end up in __getattr__ and the value isn't > present in the model's __dict__ but the attname is present in the > model._state.deferred_fields, then you know to load it from DB. I > assume there are some reasons why this wasn't done in the first > place... Maybe descriptors for custom fields would break or the above > mentioned direct __dict__ access case would fail? > > - Anssi > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
