> Indeed. If two applications each rely on different QuerySet classes, > something more fine-grained than a global setting will be needed for > them to peaceably coexist; I'd much prefer some standardized way of > extending the functionality, something we already have to an extent > via the ability to override get_query_set() in a custom manager.
That's true, and that's the more granular method of being able to achieve a similar goal, but there's currently no clean way (you could monkeypatch) of overriding the get_query_set() method on, for example, the django.contrib.auth.models.User object. I think that a combination of a customizable default global QuerySet classes, in conjunction with locally overridable get_query_set() method on custom managers gets quite close to completing this circle. > schema-evolution is separable from applications -- it's utility, and > applications codes are still compatible with each other, but different > querysets features as 3rd-party libraries could make project code > incompatible, and that's baaad. There are two simple ways that 3rd-party applications could remain compatible. They could: 1. Simply rely on the functionality provided by BaseQuerySet, which is more than adequate for the majority of tasks. 2. Ensure that their required QuerySet class is used by overriding get_query_set() on their own models and doing some sort of an assertion with isinstance() or issubclass(). The only hole in this strategy is if a 3rd-party library would like to use a built-in model (User is again a good example) and at the same time use a non-standard QuerySet. I'm still not sure how to address this issue, but perhaps a model method is in order to get a custom manager. Let me provide an example of what I'm thinking: >>> from django.contrib.auth.models import User >>> from django.db.models import Manager >>> import MyCustomQuerySet # For whatever reason, this implements group_by >>> class MyCustomManager(Manager): >>> def get_query_set(self): >>> return MyCustomQuerySet(self.model) >>> def group_by(self, *args, **kwargs): >>> return self.get_query_set().group_by(*args, **kwargs) >>> custom_manager = User.get_custom_manager(MyCustomManager) >>> print custom_manager.get(username = 'amy') # It still has all of the >>> regular manager methods. >>> <User: amy> >>> print custom_manager.group_by(username__startswith=['a', 'b', 'c', 'd']) >>> [[<User: amy>, <User: anne>, <User: ashley>], [<User: bob>, <User: bill>], >>> ... ] (Note that I have not inspected the implementation to see if this method would be easy to create, I'm just thinking about the concept at this point.) This would solve that hole that I mentioned earlier, and now third parties could rely on whichever QuerySet subclass that they wanted to because they could create their own custom managers and use them with whichever models they wanted to. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
