Hi All,
I think there may be some confusion here since I didn't actually explain
myself properly to begin with. Let's run through an example:
class Lower(Func):
function = 'LOWER'
This function will work for all core backends, but it will also work for
all third party backends. Third party backends don't *have* to implement
`as_vendor()`, it's just there incase the default doesn't work for them.
MSSQL supports the function name "LOWER", so this function will
automatically work for django-mssql.
Now let's say that a mongodb backend wants to use the Lower function, but
the function name is different. What mongo could do, is provide their own
implementation:
def mongo_lower(self, compiler, connection):
self.function = '$toLower'
return self.as_sql(compiler, connection)
setattr(Lower, 'as_mongo', mongo_lower)
# or perhaps a friendlier registration method:
Lower.register('mongo', mongo_lower) # register would internally just call
the setattr() above
I think this process is pretty good. Everyone gets to use the default
implementation for free (function signatures and names are generally pretty
stable across backends), but the option exists to easily extend or modify
the generated SQL *where needed*. I think this equally supports 3rd party
backends and function authors.
Do you think this is appropriate? Have I missed something fundamental above
where this process isn't fair to backends or library authors?
Josh
On Thursday, 19 June 2014 09:00:17 UTC+10, Carl Meyer wrote:
>
> On 06/18/2014 04:41 PM, Chris Wilson wrote:
> >>>> I think database backends should have a hook to override the SQL
> >>>> implementation of any given Function. I don't think this needs to
> >>>> imply pushing the default implementation of all Functions down into
> >>>> the database backend (that just makes life unnecessarily difficult
> >>>> for third-party Functions).
> >>>
> >>> Why does it even need a hook or monkey-patching? Why not pass the
> >>> expression tree to the SQL backend (as the most natural format for
> >>> programmatically parsing), for it to render out in backend-specific
> >>> SQL as it sees fit? Perhaps relying in inherited base methods in most
> >>> cases, and overriding a few methods where that backend needs to
> >>> render a particular feature differently?
> >>
> >> Yes - that's going all the way to the other end of the spectrum,
> >> making life easier for third-party database backends at the expense of
> >> third-party Functions. How, in your plan, is a third-party Function
> >> (which won't be recognized by any database backend's SQL emitter)
> >> supposed to provide "just works" support for all built-in database
> >> backends, presuming it needs different SQL for different backends?
> >
> > Good point, thanks :)
> >
> > If neither the backend knows about the function, nor the function about
> > the backend, then a third-party module would have to register support
> > for both (e.g. "I know how to convert a Case() Function into HSQLDB
> > SQL"). Perhaps we could have a registry where third-party modules could
> > register such support.
>
> Yes; this is what I meant by "perhaps supported by a
> public API to register additional function-implementation overrides at
> ready()" in my mail that you originally replied to.
>
> 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/981f47d6-2444-42f2-a493-50980c8fb9a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
