I agree with your assessment. The problem I suppose is that 99% of django users use a third-party app with models and queries - it's called the admin. Whether this is in practice an issue in this case I don't know - I don't think there's much aggregation goes on there - but it's nonetheless an issue.
Also, at the moment 3rd party backends have the promise of "change your backend setting to this and everything will work" - not to also change a load of imports to use their aggregation functions. Obviously if you're using backend specific things then ok, but anything Django provides should have an appropriate backend hook. Personally, I happy with the current API design now we have AppConfigs as a way for third party backends to officially monkeypatch Django - though I can see the arguments that this in itself seems like poor API design. Marc On 18 June 2014 18:18, Carl Meyer <c...@oddbird.net> wrote: > On 06/18/2014 08:08 AM, Marc Tamlyn wrote: > > Worth noting that Lookups now have exactly the same as_vendor API. The > > registration API simply allows you to overload the lookup table with a > > subclass rather than just monkeypatching. > > > > This is harder here are the classes are used directly. We could provide > > an expressions registry I guess... > > Am I missing something? It seems to me that the fact that Functions are > imported and used directly makes everything easier, and reduces the need > for monkeypatching compared to Lookups. If you need a Function in your > project (whether provided by Django or by a third-party library), and > the Function doesn't natively support the database backend you're using, > you can simply subclass it, add the appropriate as_vendor method, and > use your subclass. > > I guess the case that isn't handled as nicely is where a third-party app > is itself doing the query and using the Function. In my experience, this > is much less common - I very rarely use third-party apps that define > models or perform queries themselves. Perhaps it's more common for > others. I suppose pushing implementation down to DatabaseOperations > would make this case a little easier to handle (at the cost of making > the above case harder - a custom database backend is a bigger deal than > subclassing a Function). Personally I think in this situation the > third-party app should make the querying behavior > extendable/overridable, or if all else fails you just monkeypatch the > Function it's using with the necessary as_vendor. > > I may be missing something, but I don't see any need for / value in a > registration API for functions. Global registries should be a reluctant > last resort in API design. > > Carl > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/53A1C9F9.3090701%40oddbird.net > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1H%3DFir4Gpgm%2Btw01dsNN4w6%2BXMU0wdxYjcixUmjbAwJXQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
