On Fri, 1 Jun 2012 17:26:54 +0800
Russell Keith-Magee <russ...@keith-magee.com> wrote:
> Here's a counter-proposal: (…)
>
> So, using your example:
>
> * race.candidates.all() would use _default_manager
>
> * race.candidates('objects_all').all() would use the objects_all manager
>
> * race.candidates('objects').all() would also use _default_manager
> (but explicitly)
>
> (…)
>
> For my money, that's an explicit API that makes sense when reading the
> single query line, and doesn't require the interpolation of extra
> state/context from a router or some other context manager. It's also
> backwards compatible, because there won't be any existing code
> invoking __call__() on a manager.
FWIW, something very similar has been implemented in ticket #3871 [1],
patch `r17204-custom-reverse-managers.diff` [2], minus the __call__
notation. The patch in the ticket uses an explicit method named
`manager`, however using __call__ seems more elegant (+ 1).
Maybe the efforts from that patch can be revisited.
Best wishes,
Sebastian.
[1] https://code.djangoproject.com/ticket/3871
[2]
https://code.djangoproject.com/attachment/ticket/3871/r17204-custom-reverse-managers.diff
--
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.
