On Thursday, April 25, 2013 2:37:10 PM UTC-7, Anssi Kääriäinen wrote:
>
> On 25 huhti, 23:44, Alex Ogier <alex.og...@gmail.com> wrote:
> > On Thu, Apr 25, 2013 at 2:10 PM, Florian Apolloner <
> f.apollo...@gmail.com>wrote:
> >
> > > On Thursday, April 25, 2013 7:06:06 PM UTC+2, Adrian Holovaty wrote:
> >
> > >> Also, I should mention that this should be *optional* behavior, as
> the
> > >> current behavior is reasonable for the common case. The API for
> specifying
> > >> this "load everything" behavior is a separate discussion. Perhaps a
> keyword
> > >> argument like: User.objects.only('username', loadall=True).
> >
> > > I could imagine a Meta attribute which introduces so called "deferred
> > > groups" like SA has
> > >http://docs.sqlalchemy.org/en/latest/orm/mapper_config.html#deferred-...,
>
> > > accessing one column of a group will load all columns of the group.
> Not
> > > sure if we want that level of control, but I thought it would be worth
> to
> > > look what SA can do in this regard.
> >
> > I think groups are a very good abstraction for this problem. The two
> common
> > cases are probably "Load this column alone, because it's potentially a
> big
> > honking blob of text or binary" and "Load everything we don't have on
> this
> > object, because we are actually using it actively". Groups let you solve
> > both problems flexibly. The downside is that they might not be very DRY,
> > having to repeat group="everything" over and over if you just want to
> load
> > it all on first access.
>
> +1 to this approach.
>
> IMO load everything is a better default than one field at a time. When
> deferred field loading happens something has already gone wrong. In
> almost every case it is better to try to minimize the amount of
> queries than the amount of loaded fields. The cases where you have
> deferred multiple fields, need only one of them later on, and there is
> a field that you can't load due to potentially huge value are
> hopefully rare.
>
> But, I don't really care too much. If the objects come from DB queries
> instead of something like the use case of Adrian then if you end up
> doing deferred field loading you have already failed. So, even an
> error on deferred field access would work for my use cases of defer...
>
> - Anssi
>
A couple just quick observations.
defer and only are tasks/concepts used when doing a query based on
knowledge of your dataset - adding them to the model itself expands the
number of places where this concept is considered. This has some good and
some bad.
What happens if you have defined a group on a model, and use only a single
field for 'only' in a QS? Does it fetch the only one I've asked for, or
does it trigger the group?
Why couldn't one just defined the group in the code using .only() and pass
all the fields at the time you want.
In Adrian's case, there will always be at least 2 DB hits - one could
define the group of "lazy fields" and do something like:
>>> u = User.objects.only(*lazygroup).get(id=u.id)
I guess for something like that to be more practical, we need to expose
something on the model instance that makes it easy to see what fields are
currently deferred? Something that could easily check whether the second
load had been done, and the lazy fields were available or not.
These are mostly observations, I'm not against adding the idea of groups to
the model definition, but do think that if it can be solved at the scope of
the QS usage, where .only() and .defer() currently are used, that would be
better - one less reason to check the model definition to see how it was
set up.
-Preston
--
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.
