Browse files

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: bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
freakboy3742 committed Jan 16, 2011
1 parent 645eb2b commit 1ca9e95d4e9ec5922ce6aee6c143006b6c551e48
Showing with 22 additions and 0 deletions.
  1. +22 −0 docs/topics/db/managers.txt
@@ -274,6 +274,28 @@ it into the inheritance hierarchy *after* the defaults::
# Default manager is CustomManager, but OtherManager is
# 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:
Controlling automatic Manager types

0 comments on commit 1ca9e95

Please sign in to comment.