On Jun 1, 1:43 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> > Just as a bike-shedding thought: Would it be possible to have
> > frank.events.confirmed.all() as the syntax? I see this a tiny bit
> > cleaner. On the other hand it isn't explicit you can only use
> > the .confirmed only directly after the events, and there is the
> > possibility of clashing with queryset methods. The clash issue can be
> > solved by just using frank.events('clashing_name').all() instead of
> > frank.events.clashing_name.all() in the rare cases this is needed.
>
> True - but providing an API that avoids the clash in the first place
> is preferable, IMHO.
>
> That said, I'm not *strongly* opposed to .events.confirmed -- it just
> tastes a bit funny. I'd rather not eat it, but if if everyone else
> says I should…. :-)
As said, just bike-shedding. Lets go with the call-notation for now.
It is easy enough to bike-shed this more later. The call syntax is
clear enough, and it is explicit and should be easy to make that work.
> > How would this work with prefetch_related? Maybe
> > prefetch_related('events__confirmed')? IMHO this is an important use
> > case, as there isn't currently any possibility to use different
> > filtering, ordering etc than the one given by the default related
> > manager.
>
> That's a good point -- I hadn't thought of the consequences on
> prefetch_related. I'm not wild about overloading the __ notation to
> add the 'manager selector" interpretation. There are already
> complications differentiating between aggregates, filter clauses,
> related fields… I don't think we need to add another to this mix.
>
> How about a kwarg to prefetch_related? For example:
>
> person.prefetch_related('events', managers={'events': 'confirmed'})
>
> or maybe just use kwargs directly:
>
> person.prefetch_related(events='confirmed')
>
> If you start getting into multiple joins, it's going to get more
> complex; we might have to require a list of managers:
>
> person.prefetch_related(events__things=['confirmed', 'objects'])
This API has one problem: what if you want confirmed events in one
list, and then non-confirmed events in another?
I created a ticket where you could use R-objects for prefetch related.
The idea is that you can use any query you like, and fetch the related
objects to any attribute you like.
In short, the API is this:
SomeModel.objects.prefetch_related(
R('events', to_attr='confirmed_events',
qs=RelModel.confirmed.order_by('foo')),
)
You can chain those calls:
Person.objects.prefetch_related(
R('events', to_attr='confirmed_events',
qs=Event.confirmed.order_by('foo')),
R('confirmed_events__locations', to_attr='locations',
qs=Location.objects.order_by('name')),
)
Every Person object fetched fill have a list "confirmed_events", and
each confirmed event will have an attribute "locations".
Now, that API is a bit confusing to use, but on the other hand it
makes prefetch_related usable in very generic situations. Maybe a low-
level R-objects API for when you really need to do low-level stuff,
and then some syntax-sugar (like the events='confirmed') for the
common cases?
Of course, an API which allows the full R-object expression, but still
is easy to use for the events='confirmed' case would be perfect...
For details, see: #17001.
- Anssi
--
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.
