mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-04 02:48:35 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

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.
This commit is contained in:
Russell Keith-Magee 2012-12-15 20:13:45 +08:00
parent 1e5b0fc4d0
commit 1b646e656e
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
-----------------------