On Fri, Jun 1, 2012 at 7:28 PM, Sebastian Goll <[email protected]> wrote: > On Fri, 1 Jun 2012 17:26:54 +0800 > Russell Keith-Magee <[email protected]> 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.
Thanks for finding that ticket, Sebastian -- this is an old debate, so it doesn't surprise me that there is an old ticket covering the issue. (I also find it comforting that the ticket history reveals I'm mostly consistent in my opinions… :-) If we can leverage some/all of the code from that patch, then we absolutely should. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
