I'd like to propose a change of the Model.defaul_manager concept. My
first concern was the inability to control the default_manager when
subclassing a Model that already provides a default_manager (the base
class' manager will be added before the subclass' manager).
This could be solved by either an explicit default_manager
declaration in Meta,
my_manager = MyManager()
class Meta:
default_manager = 'my_manager'
or the convention that default_managers are called `objects` (then
you wouldn't even need the default_manager concept).
I strongly favour the latter, because it's dry and simple. Yet it's a
backwards incompatible change ..
My attempts to come up with a good example to illustrate my proposal
were in vain - and I begin to think, that it's always cleaner to keep
a single Manager (and subclass as necessary) and never ever alter
Manager.get_query_set() behaviour (or all() for that matter). Does
anybody have a good use-case that depends on multiple managers?
Here is how I would write the custom manager doc example (from [1]):
http://dpaste.com/53948/ (Those proxy methods could use a little meta-
programming.).
Has this approach any flaws? If not, shouldn't the docs advertise
this more flexible approach instead of multiple Managers?
___
Johannes
[1] http://www.djangoproject.com/documentation/model-api/#custom-
managers
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
