I strongly feel that switching around managers like that would be an example of overengineering.
The user story which drove this RFC was based on an issue which has been encountered by lots of developers, but typically solved in a single way. Django's conservative style of development is very accommodating to this 'lowest common denominator' approach to adding features. However, by adding this manager-switching feature, we're second-guessing our users' intentions, and introducing unjustified complexity to the API. Here's the change I propose: https://github.com/zacharyvoase/django/compare/master...feature-querymethod It's very light for now, I'm not sure if there are other corner cases where it breaks, but it's the simplest thing that could possibly work, and it's conceptually very easy to understand. On Jan 10, 8:30 pm, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > On Jan 10, 7:10 pm, Carl Meyer <c...@oddbird.net> wrote: > > > Having access to any manager method from any queryset, regardless of > > which manager that queryset came from, seems to me like a highly > > surprising anti-feature, not a benefit. Can you outline a realistic use > > case for it? > > Basically any time when you have multiple managers (due to model > inheritance, for example) and need to mix operations from different > managers. For example you could have an abstract base class > Publishable which defines 'publishable_manager' with one method > "visible(to_user)". Then you might need to mix methods: > News.objects.filter_by_search_params(search_params).visible(request.user) > > I do think that having some way to access methods of different > managers is needed. Otherwise if you want to use all the defined > chainable methods in a single queryset, you will need to have them in > single manager. This results in unnecessary manager multi-inheritance. > > My next idea is .use_manager(), so that you can change the queryset's > base manager on the fly. This simplifies the implementation, and is > more intuitive to begin with. The above would then be: > News.objects.filter_by_search_params(search_params).use_manager('publishabl > e_manager').visible(request.user) > > My API design skills are pretty bad, so other opinions welcome :) > > Updated patch at github (https://github.com/akaariai/django/compare/ > dynamic_man). It now has use_manager(), and checks methods only from > the manager the QuerySet came from (or from manager set > by .use_manager). It still misses @querymethod. Error messages are > messy, and there are no tests or documentation. > > I really have no time to push this forward. I hope the idea is useful. > The patch at github is in good enough state that you can try the API. > Usage is really simple. Clone the branch, and you should be able to > use any manager method which uses self.get_query_set() as its base > query. @querymethod is nothing more than a marker at this point. > > - 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.
