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.