On Thu, 2014-06-19 at 02:56 +0300, Josh Smeaton wrote:

>         
>         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?

This is pretty much how I intended this to work. There are two downsides
with this approach:
  1) We don't have .register() method. If we go with this plan we might
still be able to add .register() to 1.7 (it is a trivial classmethod).
  2) The as_vendor() method will need to do a bit more, and know a bit
more about the expression than is strictly needed. The backend approach
would be:
    def as_sql(self, compiler, connection):
        lhs_sql, lhs_params = compiler.compile(self.lhs)
        rhs_sql, rhs_params = compiler.compile(self.rhs)
        return connection.less_than_sql(lhs_sql, rhs_sql, lhs_params,
rhs_params)
# In mongo backend
    def less_than_sql(self, lhs_sql, rhs_sql, lhs_params, rhs_params):
        return "%s < %s" % (lhs_sql, rhs_sql), (lhs_params, rhs_params)

The as_vendor approach gives:
    def as_mongo(self, compiler, connection):
        lhs_sql, lhs_params = compiler.compile(self.lhs)
        rhs_sql, rhs_params = compiler.compile(self.rhs)
        return "%s < %s" % (lhs_sql, rhs_sql), (lhs_params, rhs_params)

That is, the as_{vendor} methods need to repeat the compile() calls, and
also know how to compile the internal attributes of the LessThan class.

I'm not sure how to design the backend approach in a way that is both
fast, and also allows for default implementation, and custom
implementation if a backend needs it.

As said before the lookups and transforms already use as_{vendor}. I
hope it will work just fine, but it is hard to be sure about this. If we
add the .register() API to lookups and transforms to 1.7, then we can
change how the registration works internally, and also deprecate the
current way if there is need to do that.

 - Anssi


-- 
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/1403163020.6531.252.camel%40TTY32.
For more options, visit https://groups.google.com/d/optout.

Reply via email to