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, for our core types, we can mimic SQL behaviour for nulls/empty strings, and other weird backend behaviour. It might be interesting to see a proof of concept implementing support for some of the more complex expressions like Case/When and datetime truncation with timezones. Then there are Exists() subqueries and Window functions that can't work without consulting the database, and that should probably not be implemented to fetch row by row on demand (like foreign keys without select related). If some kind of rough consensus can be reached on an implementation I think we'd probably want to see a DEP considering the tradeoffs and different opinions raised in this thread. On Sunday, 19 November 2017 22:14:46 UTC+11, [email protected] wrote: > > 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 solution as third party lib (if Django API is flexible > enough for that) > > I still do not like database approach. > * If I have list of objects, do you want to have O(n) queries? > * If calculated field is function of only model fields (no foreign keys > etc) it should work locally: some projects may have no database at all. > > > > >>Even simple comparisons can be difficult to simulate in Python. As an > example, some databases treat empty strings as null > But ORM should handle it somehow, should not it? > I want to belive that "filter(alias__isnull=True)" works identically > across all databases. > So, we need to do same on Python side. > > >>To be honest, I'm curious why the SQLAlchemy approach isn't being > discussed more here. > I think SQLAlchemy approach is good, but we should use Django ORM > expressions language. > See: we need some high-level expression language to describe functions of > models that could be > calculated both on SQL side and Python side. > And we already have it: it is Django ORM expressions language:) > We have some kind of AST for all those Q, F expressions etc, so we only > need to create evaluator for this language. > > No need to use external language, based on Python, as SQLAlchemy does. > > Why do we need > from sqlalchemy import func > func.concat(cls.first_name, ' ', cls.last_name) > > if we already have > F('first_name') + F('last_name') > ? > > > >>and supplying both the SQL side (via a method which returns a Q object, > most likely) and the Python side > But it ruin DRY idea by making author to write same logic twice (for > Python and SQL), is not it? > > Still, user may have ability to provide custom expression, > but for simple cases like "age__gt=18" we can do it "automagically". > > Django generates SQL code from its expressions. Sometimes this code is > sophisticated. > Why can't we do that for Python, if we do it for SQL? > > -- 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 receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/730ceeaa-0d14-456f-a52d-8981c015093f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
