Hi all, Our documentation on "automatic managers" [1] and related managers [2] is quite clear that automatically-created managers for related-objects access will be plain-vanilla Manager instances, unless you set "use_for_related_fields = True" on the custom Manager subclass that you use as a default manager.
Unfortunately, this documentation is not true; near as I can tell, it never has been since it was introduced. Vanilla managers are used as documented in a few places: OneToOneField related-object access, and traversing FKs and M2Ms for internal cascade-deletion purposes. But in general, related-object access for reverse-FKs and M2Ms, contrary to the documentation, will _always_ use your default manager (actually, a dynamic subclass of it) and will respect any restrictions in the get_query_set method of your default manager, even if "use_for_related_fields" is absent or explicitly set to False on your Manager subclass. I have more details, and the fix (if we want it) on ticket #14891 [3] The dilemma here is that fixing this bug is quite likely to break significant amounts of code that is relying on it. As evidence of that, when fixing it I had to also fix two places in Django's own test suite where we assumed that a custom default manager would be used for related-object access, without setting use_for_related_fields=True on the manager. So - do we (A) fix the behavior to match our documented semantics, note it in the release notes, and hope for the best? Or (B) bow to backwards-compatibility and change the documentation to match the actual behavior? Or (C) find some middle ground (a deprecation path for the current behavior)? Personally, I don't find option (B) very appealing. The current behavior isn't crippling (you can generally work around it if you need to by just not making your custom manager the default one), but it is inconsistent, hard to explain, and means "use_for_related_fields" is quite misleadingly named. Input welcome, Carl [1] http://docs.djangoproject.com/en/dev/topics/db/managers/#set-use-for-related-fields-when-you-define-the-class [2] http://docs.djangoproject.com/en/dev/topics/db/managers/#managers-for-related-objects [3] http://code.djangoproject.com/ticket/14891 -- 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.
