On Sun, 2008-03-30 at 13:31 -0700, [EMAIL PROTECTED] wrote: > > Agreed. In fact, this exact suggestion was made during the recent > > discussions about adding aggregates. I'd much rather see per-manager > > customization of Query Sets, rather than a global setting. > > What do you think about my latest proposal of a > get_custom_manager(MyManager) function on Model objects? (See the end > of my previous post to this list for an example of what I mean).
I don't like this, since it's not actually usable (in the sense that it doesn't add anything) in this form. Your earlier example had you attaching a get_custom_manager() method to, e.g., the User model, but there's no way to say what that method should return. If you want to be able to specify a different default manager for some particular use of an existing model, you're sort of after a third type of model subclassing that I've thought about but haven't implemented: subclassing an existing model and explicitly telling Django that this is only Python-level (and not database-/ORM-level) inheritance. So all the database interactions are part of the parent class(es) and the child class simply adds extra functional pieces (such as a new default manager). Nothing existing so far rules out adding this, so it's not something that has to be resolved now, which is why I haven't wasted any brain cells on it so far. This might be fairly easy to add once we work out how to spell it, since it's only saying "create absolutely no fields for this model, not even links back to the parent model and definitely don't create a database table." Then something that wanted to use a different manager (which is really what you are meaning when you say "different queryset") with a model would subclass it in this fashion and add their own manager to the subclass. Existing code doesn't care about the new behaviour of your custom manager and can safely rely on the existing behaviour it is used to (which is a good thing: you don't sabotage existing code. Existing code uses the original model class). Your new code can use the subclass to be explicit that it wants the new queryset and that's fine, since it's new code that you are writing to take advantage this, so it's hardly a burden to have to write UserSubclass instead of User. Malcolm -- Atheism is a non-prophet organization. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
