Browse files

[1.2.X] Fixed #15062 -- Documented the fact that managers must be abl…

…e to be shallow copied. Thanks to Ian Clelland for the report, and Łukasz Rekucki for the help diagnosing the problem.

Backport of r15220 from trunk.

git-svn-id: bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
1 parent 84db894 commit 73b36117232923829d73dc9806c5a1f76ab10729 @freakboy3742 freakboy3742 committed Jan 16, 2011
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 73b3611

Please sign in to comment.