Fixed #15062 -- Documented the fact that managers must be able to be shallow copied. Thanks to Ian Clelland for the report, and Łukasz Rekucki for the help diagnosing the problem.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@15220 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Russell Keith-Magee 2011-01-16 06:44:23 +00:00
parent 645eb2b26b
commit 1ca9e95d4e
1 changed files with 22 additions and 0 deletions

View File

@ -274,6 +274,28 @@ it into the inheritance hierarchy *after* the defaults::
# Default manager is CustomManager, but OtherManager is # Default manager is CustomManager, but OtherManager is
# also available via the "extra_manager" attribute. # also available via the "extra_manager" attribute.
Implementation concerns
-----------------------
Whatever features you add to your custom ``Manager``, it must be
possible to make a shallow copy of a ``Manager`` instance; i.e., the
following code must work::
>>> import copy
>>> manager = MyManager()
>>> my_copy = copy.copy(manager)
Django makes shallow copies of manager objects during certain queries;
if your Manager cannot be copied, those queries will fail.
This won't be an issue for most custom managers. If you are just
adding simple methods to your ``Manager``, it is unlikely that you
will inadvertently make instances of your ``Manager`` uncopyable.
However, if you're overriding ``__getattr__`` or some other private
method of your ``Manager`` object that controls object state, you
should ensure that you don't affect the ability of your ``Manager`` to
be copied.
.. _manager-types: .. _manager-types:
Controlling automatic Manager types Controlling automatic Manager types