Re: Building a library of SQL functions into Django

I've opened the ticket https://code.djangoproject.com/ticket/23753 to track which functions should be implemented. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop

Re: Building a library of SQL functions into Django

This discussion got a little off track, and I'd like to bring it back to the original purpose. Which SQL functions should we implement when the aggregate/annotation refactor lands? I'll take the output of this discussion and create a ticket in trac once we've at least got a start on a minimal

Re: Building a library of SQL functions into Django

On Wed, 2014-07-02 at 08:56 +0300, Anssi Kääriäinen wrote: > The overhead is likely small, but it is hard to know without > benchmarking. The WhereNode instances go through compiler.compile(), so > generating SQL for qs.filter(*lots_of_args) should tell pretty well how > much overhead there is.

Re: Building a library of SQL functions into Django

> > Still, inheritance will not work like with as_vendor(), but I am not > sure how common subclasses without custom as_sql() are > > > Nearly every Function implementation will inherit from the Func type > without providing an `as_sql`, the it will be very common if I've > understood

Re: Building a library of SQL functions into Django

Thanks for the input here - I didn't think there'd be such an aversion to directly monkey patching the function objects, but there clearly is from backend maintainers and core developers. So time to move past that and come up with something that's acceptable. The solution Anssi presented above

Re: Building a library of SQL functions into Django

On 1 juil. 2014, at 21:10, Michael Manfre wrote: > Monkey patching is not really an API hook. It's what non-core code is forced > to do when the core is not flexible enough to support what it needs. If this > is the chosen route, which is the way it appears to be heading,

Re: Building a library of SQL functions into Django

Monkey patching is not really an API hook. It's what non-core code is forced to do when the core is not flexible enough to support what it needs. If this is the chosen route, which is the way it appears to be heading, then at least try to hide the fact that it's a monkey patch and mimic SQLAlchemy

Re: Building a library of SQL functions into Django

On Tue, 2014-07-01 at 17:49 +0300, Shai Berger wrote: > I think we can reach very similar results, with a much nicer API, by letting > the backends just override the function classes. The backend specific class must be instantiated at query compile time. How is the data contained in the

Re: Building a library of SQL functions into Django

On Monday 30 June 2014 17:11:22 Josh Smeaton wrote: > This is how we think we can ask 3rd party backends to provide > implementations for functions they need to modify: > > > class DatabaseWrapper(BaseDatabaseWrapper): > > def __init__(self, *args, **kwargs): >

Re: Building a library of SQL functions into Django

This is how we think we can ask 3rd party backends to provide implementations for functions they need to modify: class DatabaseWrapper(BaseDatabaseWrapper): def __init__(self, *args, **kwargs): self.patch_functions() def patch_functions(self): """ all other

Re: Building a library of SQL functions into Django

+1, as_vendor() is IMO rather clean and expressive as a end user API. 3rd party backends are indeed a concern but we discussed this briefly on IRC today and I believe we have an acceptable solution for them, Josh is planning to write up about it. -- Loic On Monday, June 30, 2014 7:08:38 PM

Re: Building a library of SQL functions into Django

On Mon, 2014-06-30 at 12:56 +0300, Josh Smeaton wrote: > >Still, I don't see *any* advantage of doing this compared to just > providing the same implementation method in the node itself with the > as_vendor syntax > > > Me neither. I think I confused the subject when I brought up putting >

Re: Building a library of SQL functions into Django

>Still, I don't see *any* advantage of doing this compared to just providing the same implementation method in the node itself with the as_vendor syntax Me neither. I think I confused the subject when I brought up putting differences into the backend - but I was trying to highlight the

Re: Building a library of SQL functions into Django

> If this is going to be moved off SQLCompiler, I think DatabaseOperations is a better place for it because we already have DatabaseOperatoins.combine_expression. The compile method will need access to the compiler to match the signature of as_sql (and it is necessary in some cases to inspect

Re: Building a library of SQL functions into Django

On 18 June 2014 12:39, Anssi Kääriäinen wrote: > On Wednesday, June 18, 2014 4:52:11 AM UTC+3, Josh Smeaton wrote: >> >> Over the last 6 months we've been working on a fairly large refactor to >> expressions. As a brief catch up, expressions are currently F() expressions.

Re: Building a library of SQL functions into Django

On Fri, Jun 27, 2014 at 7:04 AM, Anssi Kääriäinen wrote: > This is possible to do by supplying a custom SQLCompiler class for the > backend, and overriding its .compile() method. > > Personally I don't see usage of as_vendor() as that problematic. Supplying > as_vendor

Re: Building a library of SQL functions into Django

I agree that 3rd party backends should have a hook to provide their own customisations. I still think that the as_vendor approach is useful provided that the backend has a chance to register their customisations (where required - they still automatically use the default as_sql() method if

Re: Building a library of SQL functions into Django

On Thursday, June 19, 2014 12:23:20 AM UTC+3, Carl Meyer wrote: > > On 06/18/2014 02:59 PM, Aymeric Augustin wrote: > > 2014-06-18 19:18 GMT+02:00 Carl Meyer > >: > > > > If you need a Function in your > > project (whether provided by

Re: Building a library of SQL functions into Django

Nope that's completely fine. I copied that example from the tests earlier on which interpolates connection.vendor into a string. If you know which backend you're modifying (and you should) then Func.as_vendor = .. Would be preferred. > On 19 Jun 2014, at 21:04, Shai Berger

Re: Building a library of SQL functions into Django

Hi, A minor style point: On Thursday 19 June 2014 02:56:10 Josh Smeaton wrote: > > class Lower(Func): > function = 'LOWER' > >[...] > > def mongo_lower(self, compiler, connection): > self.function = '$toLower' > return self.as_sql(compiler, connection) > > setattr(Lower,

Re: Building a library of SQL functions into Django

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

Re: Building a library of SQL functions into Django

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

Re: Building a library of SQL functions into Django

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

Re: Building a library of SQL functions into Django

Hi Carl, On Wed, 18 Jun 2014, Carl Meyer 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

Re: Building a library of SQL functions into Django

Hi Chris, On 06/18/2014 03:55 PM, Chris Wilson wrote: > Hi Carl, > > On Wed, 18 Jun 2014, Carl Meyer wrote: >> On 06/18/2014 02:59 PM, Aymeric Augustin wrote: >>> 2014-06-18 19:18 GMT+02:00 Carl Meyer >> >: >>> If you need a Function in your

Re: Building a library of SQL functions into Django

Hi Carl, On Wed, 18 Jun 2014, Carl Meyer wrote: On 06/18/2014 02:59 PM, Aymeric Augustin wrote: 2014-06-18 19:18 GMT+02:00 Carl Meyer >: If you need a Function in your project (whether provided by Django or by a third-party library), and the

Re: Building a library of SQL functions into Django

On 06/18/2014 02:59 PM, Aymeric Augustin wrote: > 2014-06-18 19:18 GMT+02:00 Carl Meyer >: > > 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

Re: Building a library of SQL functions into Django

2014-06-18 19:18 GMT+02:00 Carl Meyer : > 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

Re: Building a library of SQL functions into Django

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

Re: Building a library of SQL functions into Django

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

Re: Building a library of SQL functions into Django

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

Re: Building a library of SQL functions into Django

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

Re: Building a library of SQL functions into Django

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

Re: Building a library of SQL functions into Django

2014-06-18 15:19 GMT+02:00 Josh Smeaton : > At the moment the API sanctions monkey patching by providing the > as_vendor() method > Yes, I'm not happy with the as_() API either, because it creates a large asymmetry between the core and non-core backends. -- Aymeric. --

Re: Building a library of SQL functions into Django

At the moment the API sanctions monkey patching by providing the as_vendor() method (from the tests): def lower_case_function_override(self, compiler, connection): sql, params = compiler.compile(self.expressions[0]) substitutions =

Re: Building a library of SQL functions into Django

Would it be possible to have some sort of registration pattern, allowing people to import per-backend and per-project libs to override and extend the various available functions? I realise this is nothing more than a sanctioned form of monkey patching, but it would at least provide a common

Re: Building a library of SQL functions into Django

On Wednesday, June 18, 2014 4:52:11 AM UTC+3, Josh Smeaton wrote: > > Over the last 6 months we've been working on a fairly large refactor to > expressions. As a brief catch up, expressions are currently F() > expressions. I've expanded their scope to include Aggregates. As a > by-product of