#13313: Custom Default Manager with extra __init__ arguments fails if model is
used
in a ManyToManyField
---------------------------------------------------+------------------------
Reporter: cbw...@gmail.com | Owner: nobody
Status: new | Milestone: 1.2
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
ManyToManyField, Manager
Stage: Design decision needed | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------------+------------------------
Comment (by cbw...@gmail.com):
Assuming you want to support this feature, one main way I can think of is
by using copy.deepcopy to copy the the already instantiated default
manager from the model, and then monkeypatch in the currently subclassed
methods.
Another possibility is basically making a ManyRelatedManagerProxy, which
either proxies the other manager methods explicitly or overrides
__getattribute__ to run the originally wanted method from the already
instantiated default model or the new subclass m2m functions. In effect,
make the proxy be a virtual subclass, so that __init__ is not needed and
so any manager state is preserved (if, for example, get_query_set() uses
an arg originally passed to __init__)
Both options have costs, but already the
ReverseManyRelatedObjectsDescriptor generates a new subclass for each call
without caching. Why not cache the (or with this change, the
monkeypatched) manager returned by __get__ directly on the
ReverseManyRelatedObjectsDescriptor?
--
Ticket URL: <http://code.djangoproject.com/ticket/13313#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-upda...@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.
