Re: [off topic] Re: models.CalculatedField feature

2017-11-18 Thread James Bennett
To be honest, I'm curious why the SQLAlchemy approach isn't being discussed more here. Implementing a calculated-field property decorator, and supplying both the SQL side (via a method which returns a Q object, most likely) and the Python side wouldn't be too difficult to implement, and avoids the

Re: [off topic] Re: models.CalculatedField feature

2017-11-18 Thread Anssi Kääriäinen
Even simple comparisons can be difficult to simulate in Python. As an example, some databases treat empty strings as null. Still, autogenerating the Python side of simple computations is an interesting idea. At least worth a try. There are some hard problems if trying to push all computations to

Re: [off topic] Re: models.CalculatedField feature

2017-11-18 Thread Shai Berger
On Saturday 18 November 2017 21:32:47 ilya.kazakev...@jetbrains.com wrote: > > Such computations always end up slightly different in some > > edge cases > > I agree. > We can document this fact. Model authors should be aware that they are not > allowed to use anything but literals. All other funct

Re: [off topic] Re: models.CalculatedField feature

2017-11-18 Thread Josh Smeaton
Re-reading your reply, I think I've misunderstood your intent there (I didn't realise who the author was). Please disregard my previous reply. On Sunday, 19 November 2017 09:59:44 UTC+11, Josh Smeaton wrote: > > Until you want to aggregate or filter on that calculation, and perform > that filter

Re: [off topic] Re: models.CalculatedField feature

2017-11-18 Thread Josh Smeaton
Until you want to aggregate or filter on that calculation, and perform that filtering in the database rather than pulling back millions of records to do so in python. The database *must* be involved. On Sunday, 19 November 2017 06:32:48 UTC+11, ilya.ka...@jetbrains.com wrote: > > Such computatio

Re: [off topic] Re: models.CalculatedField feature

2017-11-18 Thread ilya . kazakevich
> > Such computations always end up slightly different in some > edge cases > I agree. We can document this fact. Model authors should be aware that they are not allowed to use anything but literals. All other functions are used on their own risc. I believe that comparition of two integers or

[off topic] Re: models.CalculatedField feature

2017-11-18 Thread Shai Berger
On Saturday 18 November 2017 15:06:20 Shai Berger wrote: > > 1) Make all computations in Python. This means the feature can be supported > only on databases which can run Python as part of their queries; I'm not > quite sure about the details, but I think PG can. I'm certain none of the > other co