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...
Marc
On 18 Jun 2014 14:57, "Josh Smeaton" <josh.smea...@gmail.com> wrote:
> Consider library authors:
>
> class WindowFunction(Func):
> def as_sql(self, compiler, connection): # standard implementation
> return compiler.compile(self.expressions)
> def as_sqlite(self, compiler, connection): # unsupported first party
> backend
> raise NotSupportedException("WindowFunction not supported with
> SQLite")
> def as_mssql(self, compiler, connection): # third party backend
> self.function = "SlightlyDifferentFunctionName"
> return self.as_sql(compiler, connection)
>
>
> I think the as_{vendor} makes all backends equal - both core and non-core
> backends. We all use the same API. We can anticipate some of the backends
> that will use a particular function, but make it possible and easy for
> other backends to jump onboard. This is in contrast to the existing process
> of providing implementations directly inside the backend
> (DatabaseOperations). But this is a part that I'm struggling with. Should
> we push Function implementations down into DatabaseOperations, or continue
> with the as_vendor? I really like the as_vendor implementation for
> Expressions since there will be a large number of Expressions which will
> work across all backends with the default as_sql(), but there is an easy
> extension point. I see libraries providing a larger set of expressions than
> django does.
>
> I don't like the setattr(Expression.. ) syntax for providing
> implementations though. I'd probably prefer a .register(vendor, function).
>
> Josh
>
> On Wednesday, 18 June 2014 23:31:39 UTC+10, Aymeric Augustin wrote:
>>
>> 2014-06-18 15:19 GMT+02:00 Josh Smeaton <josh.s...@gmail.com>:
>>
>>> At the moment the API sanctions monkey patching by providing the
>>> as_vendor() method
>>>
>>
>> Yes, I'm not happy with the as_<vendor>() API either, because it creates
>> a large asymmetry between the core and non-core backends.
>>
>> --
>> Aymeric.
>>
> --
> 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/bc9df00a-3aa0-4307-885e-25c1bc59d77f%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/bc9df00a-3aa0-4307-885e-25c1bc59d77f%40googlegroups.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/CAMwjO1F02XbyM-mH7V3x93SX9V6oUUnKcmCN2fL%2BnthO_Q5THA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
