The focus then is on how to let the developer specify what they want in the
same query and what they want in a different query.
Select_related currently adds same query stuff and prefetch_related
adds separate query stuff. So what if we added a way for a select_related
to be bolted onto a prefetch_related. A "base" argument to select_related
seems like a reasonable way of doing this. The original example was:
> Restaurant.objects.prefetch_related('best_pizza__toppings__topping_type')
We could rewrite it as:
>
Restaurant.objects.prefetch_related('best_pizza__toppings").select_related(base='best_pizza__toppings",
"topping_type')
The prefetch_related can be inferred from the base, so we could shorten it
to:
> Restaurant.objects.select_related(base='best_pizza__toppings",
"topping_type')
Each unique unique base produce a new db query, multiple select_relateds
with the same base are done as one query.
I think that's actually a complete system in itself, prefetch_related is
just shorthand and can be implemented as:
def prefetch_related(queryset, *args):
for arg in args:
queryset = queryset.select_related(base=arg)
return queryset
The only quirk comes from the original example again, what does this do?
Restaurant.objects.prefetch_related('best_pizza__toppings__topping_type')
Tired, but I think there is something to this line of thinking.
On Mon, Nov 26, 2012 at 6:13 PM, Luke Plant-2 [via Python] <
ml-node+s6n4997386...@n6.nabble.com> wrote:
> On 20/11/12 12:08, tolomea wrote:
> >> it should do exactly what the developer asks.
> >
> > How do I, the developer, request that it use select_related for
> topping_type
> > part of the best_pizza__toppings__topping_type example given above?
>
> Sorry for the slow reply. At the moment, there is no way to specify
> that. (Unless you can use a default manager to do it, but that might be
> constrained by other things).
>
> It would be nice to come up with a better API for this kind of thing.
> SQLAlchemy may have some good ideas in the way it does eager loading - I
> believe it has support for equivalents of both select_related and
> prefetch_related.
>
> What I'm saying is that in the absence of that better API, or some way
> of specifying the query you want, we shouldn't guess and convert one
> optimisation into another.
>
> Luke
>
> --
> OSBORN'S LAW
> Variables won't, constants aren't.
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to [hidden
> email]<http://user/SendEmail.jtp?type=node&node=4997386&i=0>.
>
> To unsubscribe from this group, send email to [hidden
> email]<http://user/SendEmail.jtp?type=node&node=4997386&i=1>.
>
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://python.6.n6.nabble.com/Could-prefetch-related-be-modified-to-utilize-select-related-for-ForeignKey-relations-tp4486127p4997386.html
> To unsubscribe from Could prefetch_related be modified to utilize
> select_related for ForeignKey relations?, click
> here<http://python.6.n6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4486127&code=Z29yZG9uLndyaWdsZXlAZ21haWwuY29tfDQ0ODYxMjd8LTMzNTA0Nzk3NQ==>
> .
> NAML<http://python.6.n6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context:
http://python.6.n6.nabble.com/Could-prefetch-related-be-modified-to-utilize-select-related-for-ForeignKey-relations-tp4486127p4997399.html
Sent from the django-developers mailing list archive at Nabble.com.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
