Re: Changes to ORM expressions API

After spending a bit more time looking over the patch, I think the best and most logical place for a database backend to hook in to the as_vendor override is in SQLCompiler.compile, which is where Django checks the node for the vendor specific override and then calls it. Database backends are alre

Re: Changes to ORM expressions API

manfre has raised some issues about registering implementations in IRC. I had been assuming that AppConfigs could be used for backends to register their changes, but that would require users to modify their INSTALLED_APPS for that to work. Otherwise, backends never really get an opportunity to

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 part

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 make

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 unn

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 project (whether provided

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 mailto:c...@oddbird.net>>: If you need a Function in your project (whether provided by Django or by a third-party library), and the Function doesn't natively s

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 the database backend y

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 method, and > use

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 aggre

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 issu

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 cou

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 O

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 NotSupportedException("Win

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. -- You received this messa

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 = dict(function=self.f

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 patter

Re: Strange behavior when running simple query via script versus view code

2014-06-18 9:48 GMT+02:00 Shai Berger : I'm not sure -- but it may be that your 'fixupthemes.FixupThemeTime' model > is > not loaded in the script. Try adding an explicit import of it before the > query. > > If this works, then: > > a) The issue has been resolved in 1.7 by the app-load refactor; >

Re: Strange behavior when running simple query via script versus view code

Hi, On Tuesday 17 June 2014 16:41:04 Jason Skicewicz wrote: > > > > AttributeError: 'str' object has no attribute '_meta' > > I'm at a loss as to why this is happening, but through debugging, when > Django attempts to get the field via script, lookup_model is a string > whereas in the view code,

Re: Problem in doing Calcultion in django Application

On Wed, Jun 18, 2014, Muskan arora wrote: >I have a problem in calculating Sum. > my models.py is as follows :- You'll get answers to your questions on the django-users email list, - the web interface is . The list you've posted to is dj

Problem in doing Calcultion in django Application

I have a problem in calculating Sum. my models.py is as follows :- class Book(models.Model): book_text = models.CharField(max_length=200) price = models.IntegerField(default=0) tax = models.DecimalField(max_digits=10, decimal_places=2) class Author(models.Model): book = models.For

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 thi