#14891: use_for_related_fields=False is not honored by reverse FK or M2M related
managers
-------------------------------------+-------------------------------------
Reporter: sdksho@… | Owner: nobody
Type: Bug | Status: new
Milestone: | Component: Database layer
Version: 1.2 | (models, ORM)
Resolution: | Severity: Normal
Triage Stage: Design | Keywords: Manager
decision needed | ManyToManyField
Needs documentation: 0 | use_for_related_fields
Patch needs improvement: 0 | Has patch: 0
| Needs tests: 0
-------------------------------------+-------------------------------------
Changes (by carljm):
* type: New feature => Bug
Comment:
This isn't just M2M fields, it's reverse FKs as well.
`ForeignRelatedObjectsDescriptor`, `ManyRelatedObjectsDescriptor`, and
`ReverseManyRelatedObjectsDescriptor` all unconditionally use
`_default_manager` rather than `_base_manager` as the superclass for the
dynamic manager they create (the only exception is for internal deletion
purposes), and `ForeignRelatedObjectsDescriptor.create_manager` and
`create_many_related_manager` both create a dynamic manager class whose
`get_query_set` method gets its initial queryset from `super()`. In other
words, regardless of the value of `use_for_related_fields` you always get
a related-manager that is a subclass of and behaves the same as your
default manager.
The only place "use_for_related_fields = False" (the default, in theory!)
is actually honored currently is for `OneToOneField`
(`SingleRelatedObjectDescriptor` and
`ReverseSingleRelatedObjectDescriptor` both use `_base_manager`), and
internal deletion traversal.
This definitely does not match the documented behavior... and fixing it is
also likely to break people's code. The fix is simple, if we actually want
to make it - just always use `_base_manager` instead of `_default_manager`
in all of those descriptors. (`ensure_default_manager` already sets
`_base_manager` to be the same as `_default_manager` if
`use_for_related_fields = True`).
I'm changing the categorization here to "bug." When we've clearly
documented how a feature is supposed to work, and it doesn't work, fixing
it is not a "new feature," regardless of how backwards-incompatible the
fix is. Our usual policy is that we fix bugs regardless -- but I'm sure
exceptions to that have been made in the past when there was a likelihood
of breaking lots of code, and this might be a case for such an exception.
--
Ticket URL: <http://code.djangoproject.com/ticket/14891#comment:3>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
