On 04/18/2011 12:47 PM, Luke Plant wrote: >> 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)? > > I vote for A - fix the bug.
That's my leaning, too. The biggest pain this would cause would be for people using third-party custom managers that don't set use_for_related_fields, and relying on it being used for related fields anyway. Since use_for_related_fields currently must be set as a class attribute, not an instance attribute, they would either need to subclass the third-party manager just in order to add use_for_related_fields=True, or they would need to monkeypatch it on. In my mind, this reveals a different problem: the author of a custom Manager subclass is not necessarily the best person to decide whether that manager should be used for related fields in a particular use of it. Making Manager.__init__ accept a use_for_related_fields argument is problematic for backwards-compat with existing subclasses, but we could respect it if set directly as an instance attribute: objects = MyCustomManager() objects.use_for_related_fields = True I may open that as a separate ticket. Carl -- 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.
