Bei der Gruppe, für die Sie eine Mitteilung verfassen, handelt es sich um eine Usenet-Gruppe. Wenn Sie in dieser Gruppe Nachrichten posten, ist Ihre E-Mail-Adresse für jeden im Internet sichtbar
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?
Is there a rationale for multiple managers per model? Or is it a that's-how-it's-always-been thing? If I missed something obvious, I would have received a "wrong list or rtfm" reply by now, supposedly.
{{{ class AManager(Manager): pass
class BManager(Manager): pass
class A(Model): a_objects = AManager() class Meta: abstract = True
class B(Model): b_objects = BManager() class Meta: abstract = True
class C(A,B): objects = Manager()
class D(B,A): objects = Manager()
}}}
Now C._default_manager == C.a_objects and D._default_manager == D.a_objects. If A and B come from different modules _default_manager will be picked depending on import order.
If this is by design, I'd be happy with a "wontfix" reply. I'm not using multiple managers anyway.
> 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,
> 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?
On Mon, Jun 16, 2008 at 9:22 AM, Johannes Dollinger
<johannes.dollin...@einfallsreich.net> wrote: > Is there a rationale for multiple managers per model?
Yes, and I at least use them all the time. For example, I'll often have one manager that does no special filtering, and another that only returns things with a "live" or "published" status. Once you start working with them, you find lots of uses for multiple-manager tricks like this.
-- "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
> On Mon, Jun 16, 2008 at 9:22 AM, Johannes Dollinger > <johannes.dollin...@einfallsreich.net> wrote: >> Is there a rationale for multiple managers per model?
> Yes, and I at least use them all the time. For example, I'll often > have one manager that does no special filtering, and another that only > returns things with a "live" or "published" status. Once you start > working with them, you find lots of uses for multiple-manager tricks > like this.
> -- > "Bureaucrat Conrad, you are technically correct -- the best kind of > correct."
So then what is the difference between a Manager and a QuerySet?
Nearly everything would work identically if Manager were simply:
class Manager(QuerySet):
pass
(except actually keeping the magic that connects it to the model
class.)
It would be exactly identical, except that:
* the assignment to self.model is deferred until after the class is
created (QuerySet requires it as an __init__ parameter)
* Model.objects doesn't repr() to anything interesting
If those differences don't matter, why have an unnecessary concept?
If those differences do matter, is there a generally useful technique
or pattern here?
<johannes.dollin...@einfallsreich.net> wrote:
> If you're just want different querysets you can use something like
> this:http://dpaste.com/53948/.
> Things.live.all() vs Things.objects.live().
> Am 16.06.2008 um 16:37 schrieb James Bennett:
> > On Mon, Jun 16, 2008 at 9:22 AM, Johannes Dollinger
> > <johannes.dollin...@einfallsreich.net> wrote:
> >> Is there a rationale for multiple managers per model?
> > Yes, and I at least use them all the time. For example, I'll often
> > have one manager that does no special filtering, and another that only
> > returns things with a "live" or "published" status. Once you start
> > working with them, you find lots of uses for multiple-manager tricks
> > like this.
> > --
> > "Bureaucrat Conrad, you are technically correct -- the best kind of
> > correct."
> On Mon, Jun 16, 2008 at 9:44 AM, Johannes Dollinger > <johannes.dollin...@einfallsreich.net> wrote: >> If you're just want different querysets you can use something like >> this: http://dpaste.com/53948/.
> Or I can use managers and also add other supporting methods (which I > also often do).
You could as stick them in a single manager as well (and wouldn't have to remember which method is available via which manager). My point is that one manager per model would be enough to do anything you can do with multiple managers (and if you want modified querysets you get a little extra flexibility if you just subclass QuerySet). Therefore (imho) the cleanest solution for the problem with _default_manager and model inheritance appears to get rid of multiple managers. I don't really expect this to be accepted as it would break lots of existing code. But there should be a way to bypass the Manager.creation_counter magic.
On Mon, Jun 16, 2008 at 1:48 PM, Johannes Dollinger
<johannes.dollin...@einfallsreich.net> wrote: > You could as stick them in a single manager as well (and wouldn't > have to remember which method is available via which manager). > My point is that one manager per model would be enough to do anything > you can do with multiple managers (and if you want modified querysets > you get a little extra flexibility if you just subclass QuerySet).
Simply "being enough" won't cut it though, because you'd end up having to do some very ugly things and crowding up your single manager with a lot of stuff that'd make more sense logically broken out.
It'd also hurt the reusability of managers (which is a big advantage I and others have taken advantage of), because you wouldn't be able to keep methods specific to a single model separate from methods which aren't, at least not without introducing a whole chain of manager classes inheriting from each other to bring in the right sets of methods.
-- "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
> It'd also hurt the reusability of managers (which is a big advantage I > and others have taken advantage of), because you wouldn't be able to > keep methods specific to a single model separate from methods which > aren't, at least not without introducing a whole chain of manager > classes inheriting from each other to bring in the right sets of > methods.
That's exactly what I do now - I have model specific managers and use them as bases for submodel managers. There are no reusability drawbacks and you can split functionality as needed. You could add a manager_mixin attribute to Meta to make the parallel inheritance structure (models and managers) more convenient.
The QuerySet method examples [1] mostly use the corresponding Manager proxy method. Probably QuerySet.create() exists to use querysets where managers are expected.
> doesn't do what you'd expect. (Though `cat.article_set.create` should > work.) Has that actually confused anyone?
> -Ken
> On Jun 16, 2:57 pm, Johannes Dollinger > <johannes.dollin...@einfallsreich.net> wrote: >>> So then what is the difference between a Manager and a QuerySet?
>>> Nearly everything would work identically if Manager were simply:
>>> class Manager(QuerySet): >>> pass
>>> (except actually keeping the magic that connects it to the model >>> class.)
>> Utility methods in managers wouldn't make much sense if Manager was a >> QuerySet:
|
