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
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
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
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
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
+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
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
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
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
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
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
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
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-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
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
>
> 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
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
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?
>
> >>
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
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
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
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
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
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.
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
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
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
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
28 matches
Mail list logo