On 9/9/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Thinking a little higher level, it feels like we should be avoiding the idea > of a 'default' manager as much as possible. We let people define multiple > managers, but we fall back to the default far too often.
Agreed; there are a couple of tickets out for situations where we inappropriately fall back to the model's default manager, and those situations aren't all that uncommon. What's worse, it means you sometimes end up in a situation with no good solution, because no matter how you set up your managers there's something that won't work the way you'd expect it to. For example (taken from a real-world app I've worked on)... Consider a weblog app with an Entry model and a Category model: * An Entry can be either "live" or "draft". * There's a many-to-many relation between Entry and Category. Now, the obvious thing to do is set up a custom manager which only returns "live" entries. Since for most purposes that's what we want, we make it the default manager. Then, to keep things working in the admin, we add a vanilla instance of models.Manager, and tell the admin to use that instead of the default manager. Except this doesn't work; the manager we've specified for the admin to use will only actually be used on change lists; editing an object uses the model's default ChangeManipulator which, of course, uses the model's default manager. Se we end up with objects that we can see in the change list, but not edit (this is ticket #1855). But if we switch the order of manager around so that the "vanilla" one becomes the default (which restores the ability to edit all entries in the admin), now we run into problems with the Entry-Category relation; when we have a Category and want to fetch related Entry instances, the many-to-many descriptor uses the default manager for Entry and doesn't (so far as I know) offer any way to change that. So we end up getting all entries, not just "live" ones. Since the latter can be worked around by writing custom methods on the Category model which duplicate the filtering logic of the custom manager on Entry, that's what I ended up doing, but that's only marginally less ugly than not having the functionality a custom manager should be able to provide. It'd be awfully nice not to end up in those sorts of "no-win" situations... -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
