On 06/18/2014 11:40 AM, Marc Tamlyn wrote: > 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.
Point taken re the admin - but I doubt the core admin will be changed to use Functions (in a non-overridable way). Maybe I'm wrong. > 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. Yeah, I think this is the strongest argument. The problem is that we want to support both third-party Functions and third-party database backends, and sometimes getting those to work together will require integration work. The question is whether that integration happens via a custom database backend (more work, but always under the control of the integrator) or a customized Function (simpler and less invasive, but requires monkeypatching if the Function is used in third-party code). If we choose the former, we're making third-party Functions a second-class citizen. If we choose the latter, we're making third-party database backends the second-class citizen. I can see good arguments for either of those choices. Maybe a form of registry is a reasonable answer. I wouldn't see it as a registry of Functions; in the common case Functions shouldn't require any registration. But it could be a registry of "Function compiler overrides" - if your project uses a third-party Function that doesn't output the correct SQL for your database backend, you can call a method on your backend that registers a different SQL translation for that particular Function. It's still a bit monkeypatchy, but it seems as good as the other available options. Carl > 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 > <mailto: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 > <mailto:django-developers%2bunsubscr...@googlegroups.com>. > To post to this group, send email to > django-developers@googlegroups.com > <mailto: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 > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto: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 > <https://groups.google.com/d/msgid/django-developers/CAMwjO1H%3DFir4Gpgm%2Btw01dsNN4w6%2BXMU0wdxYjcixUmjbAwJXQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. > 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/53A1D39B.4020001%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
