mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-24 06:06:09 +00:00
Code Issues 32 Releases Wiki Activity

[1.5.X] Fixed #19384 -- Documented the behavior of custom managers on abstract models.

Browse Source 
This documents the behavior introduced by cc337a74, which is BACKWARDS
INCOMPATIBLE for any attempt to invoke a method on a manager using the
abstract class as the calling class (e.g., AbstractBase.objects.do_something())

Thanks to mhsparks for the report.

Backport of 1b646e656e from master.
This commit is contained in:
Russell Keith-Magee
2012-12-15 20:13:45 +08:00
parent 084a8e2959
commit 9cf566233b
2 changed files with 30 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
docs/topics/db/managers.txt
View File

@@ -274,6 +274,21 @@ it into the inheritance hierarchy *after* the defaults::
# Default manager is CustomManager, but OtherManager is
# also available via the "extra_manager" attribute.
Note that while you can *define* a custom manager on the abstract model, you
can't *invoke* any methods using the abstract model. That is::
ClassA.objects.do_something()
is legal, but::
AbstractBase.objects.do_something()
will raise an exception. This is because managers are intended to encapsulate
logic for managing collections of objects. Since you can't have a collection of
abstract objects, it doesn't make sense to be managing them. If you have
functionality that applies to the abstract model, you should put that functionality
in a ``staticmethod`` or ``classmethod`` on the abstract model.
Implementation concerns
-----------------------