Re: models.CalculatedField feature

2023-01-02 Thread Jeremy Nauta
FYI I have posted a tentative first draft of this feature, feedback is greatly appreciated! https://github.com/django/django/pull/16417 https://code.djangoproject.com/ticket/31300 On Saturday, February 3, 2018 at 5:06:08 p.m. UTC-7 raider...@gmail.com wrote: > Hey, > > So has this stalled? Be

Re: models.CalculatedField feature

2018-02-03 Thread Robert Roskam
Hey, So has this stalled? Because this looked really great, and I was looking forward to seeing it! On Monday, November 20, 2017 at 10:31:31 PM UTC-5, ilya.ka...@jetbrains.com wrote: > > Thank you all. > > I've created a feature request https://code.djangoproject.com/ticket/28822 > and > wil

Re: models.CalculatedField feature

2018-01-30 Thread Silvio
I implemented this feature by having a default manager that overrides get_queryset. it loops over any calculated field declared on the model and annotates that model. Always. The main issue I ran into is that these fields were not query-able when used for related lookups. So: Customer.objects

Re: models.CalculatedField feature

2017-11-20 Thread ilya . kazakevich
Thank you all. I've created a feature request https://code.djangoproject.com/ticket/28822 and will try to implement in my Django fork next week. I am not Django source code guru, so any help is welcome:) -- You received this message because you are subscribed to the Google Groups "Django deve

Re: models.CalculatedField feature

2017-11-19 Thread Shai Berger
On Monday 20 November 2017 02:49:09 ilya.kazakev...@jetbrains.com wrote: > Ok, can we have > > is_adult = models.DBCalculatedField(ExpressionWrapper(Q(age__gt=18), > output_field=BooleanField())) > > Any query for model with this field will be automatically annotated with > .annotate(is_adult =E

Re: models.CalculatedField feature

2017-11-19 Thread Robert Roskam
+1 for this approach. On Sunday, November 19, 2017 at 7:49:09 PM UTC-5, ilya.ka...@jetbrains.com wrote: > > Ok, can we have > > is_adult = models.DBCalculatedField(ExpressionWrapper(Q(age__gt=18), > output_field=BooleanField())) > > Any query for model with this field will be automatically anno

Re: models.CalculatedField feature

2017-11-19 Thread ilya . kazakevich
Ok, can we have is_adult = models.DBCalculatedField(ExpressionWrapper(Q(age__gt=18), output_field=BooleanField())) Any query for model with this field will be automatically annotated with .annotate(is_adult =ExpressionWrapper(Q(age__gt=18), output_field=BooleanField())) We may use F fields a

Re: models.CalculatedField feature

2017-11-19 Thread Shai Berger
On Sunday 19 November 2017 13:14:46 ilya.kazakev...@jetbrains.com wrote: > Ok, I see not everyone are happy with idea of ORM expression calculated on > Python side:) As the main "not happy" (I think), I should say, it's not the calculation-on- Python-side per se that bugs me; it's the claim that t

Re: models.CalculatedField feature

2017-11-19 Thread Josh Smeaton
Introducing an `as_python` to the expression API would probably work. It'd involve a lot of work to implement for all supportable expression types. Considering there are many 3rd party / user code expressions in the wild without as_python, we'd need to find a way to fail gracefully. However, fo

Re: models.CalculatedField feature

2017-11-19 Thread ilya . kazakevich
Ok, I see not everyone are happy with idea of ORM expression calculated on Python side:) We can: * Provide two different backends (Database-based and Python-based or "run python in database" backend) for calculated field * Or provide python-based backend as third party lib * Or provide whole so

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

Re: models.CalculatedField feature

2017-11-18 Thread Shai Berger
On Thursday 16 November 2017 14:08:20 Sjoerd Job Postmus wrote: > I disagree with not being able to calculate it locally (without the > database): such a calculation depends on other fields. What if a dependent > field is updated, but the object is not yet saved. What should the value > be? > > >>

Re: models.CalculatedField feature

2017-11-17 Thread Mariusz Felisiak
Some databases such as Oracle [1] or MySQL [2] support virtual (generated) columns based on expressions. IMO it will be great (and should be quite straightforward) to add them to Django. We can take this approach into account. Mariusz [1] https://oracle-base.com/articles/11g/virtual-columns-11

Re: models.CalculatedField feature

2017-11-16 Thread ilya . kazakevich
Thank you for your intereset this on feature. I belive this functionality should not delegete everything to database: one of the cooliest Django features is that models do not require database: they could be just storage of *business* logic (that is why we call them *fat*). I can even fill my mo

Re: models.CalculatedField feature

2017-11-16 Thread Tom Forbes
I think without client-side Python execution of these functions it greatly limits the use of this feature. In the cases I've seen you have a bunch of `qs.filter(age__gt=18)` scattered around everywhere and a separate `can_drink` function of property. Without the `can_drink` function returning the c

Re: models.CalculatedField feature

2017-11-16 Thread Sjoerd Job Postmus
I disagree with not being able to calculate it locally (without the database): such a calculation depends on other fields. What if a dependent field is updated, but the object is not yet saved. What should the value be?>>> c.age, c.is_adult17, False>>> c.age = 40>>> c.age, c.is_adult40, FalseWould

Re: models.CalculatedField feature

2017-11-16 Thread Marc Tamlyn
I like the idea, and have a number of concrete use cases I would use it for. In one case I even have a custom manager which always applies a particular `.annotate()` already, so it can be filtered and accessed on the model. I am inclined to agree with Shai that the fully database version should at

Re: models.CalculatedField feature

2017-11-15 Thread Shai Berger
On Thursday 16 November 2017 07:21:38 Josh Smeaton wrote: > > I don't agree with reimplementing lookups/transforms/funcs to produce the > python version of a SQL concept. It's a leaky abstraction. Instead, I'd > prefer the model author provides their python calculation: > > is_adult = models.

Re: models.CalculatedField feature

2017-11-15 Thread Josh Smeaton
I too have seen computed properties poorly implemented as model functions/properties, only some of the time matched with an appropriate database selector. I think there's a lot of merit in the idea. I don't agree with reimplementing lookups/transforms/funcs to produce the python version of a SQ

Re: models.CalculatedField feature

2017-11-15 Thread Anthony King
Hey, this is something I'd like to get involved in. Last year I began prototyping something (albeit with an awful name) that resembled sqlalchemy's hybrid properties. I'll spend a bit of time in a few hours sprucing it up to better match their naming, and link it here if anyone is interested. On

RE: models.CalculatedField feature

2017-11-15 Thread Tom Forbes
SQLAlchemy has this, through a feature called Hybrid Attributes: http://docs.sqlalchemy.org/en/latest/orm/extensions/hybrid.html Every Django project i've worked on has had to tackle this problem, often poorly. You usually end up with an instance method and a kind of duplicate manager method, or s

RE: models.CalculatedField feature

2017-11-15 Thread Matthew Pava
I handle that situation quite differently. I have a model manager that annotates different fields to the queryset depending on when I need them. For your example, I would have something like this: class CustomerQuerySet(models.QuerySet): def with_allowed_to_drink(self): return self.anno