On 29 huhti, 00:09, ptone <pres...@ptone.com> wrote:
> 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.
How about taking a different approach? If a Model.refresh(*fields)
method is introduced and if deferred loading happens through
instance.refresh(), then by overriding the method you can alter the
deferred loading strategy in any way you wish. In addition, if
refresh() takes an all_deferred kwarg, then the original problem can
be solved in this way:
def refresh(self, *fields, **kwargs):
kwargs['all_deferred'] = True
super(User, self).refresh(*fields, **kwargs)
There are other use cases where model.refresh() would be useful. The
currently recommended way to refresh an instance is to do obj =
SomeModel.objects.get(pk=obj.pk), but this doesn't work nicely in all
cases.
While having Meta.deferred_groups or QuerySet.only(*fields,
loadall=True/False) would be a bit nicer API, I am still of the
opinion that use cases where it actually matters how deferred loading
happens are rare. The above gives a way to customise deferred loading
strategy. For the concrete use cases I have seen so far
overridden .refresh() should be enough.
- 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.
