#25425: Enforce calling resolve_expression before as_sql on all expressions
-------------------------------------+-------------------------------------
     Reporter:  jarshwah             |                    Owner:  nobody
         Type:  Bug                  |                   Status:  new
    Component:  Database layer       |                  Version:  master
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:
                                     |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by jarshwah):

 Yes, but what about a resolvable nested within a non-resolvable. The docs
 also (perhaps incorrectly) point out that resolve_expression is a place to
 do validation
 
https://docs.djangoproject.com/en/1.8/ref/models/expressions/#django.db.models.Expression.resolve_expression

 > Provides the chance to do any pre-processing or validation of the
 expression before it’s added to the query. resolve_expression() must also
 be called on any nested expressions. A copy() of self should be returned
 with any necessary transformations.

 If we want to support expressions as filters, then we're probably going to
 have to support F() within a WhereNode():

 {{{
 Model.objects.filter(Greater(F('field'), 3)) -> WhereNode()
 }}}

 That WhereNode will have to be resolved at some point so that the nested
 F() is also resolved. This was the major source of problems when
 converting transforms into expressions:

 
https://github.com/django/django/blob/f2975c021d247bf8c6a5fc23988639c636da86f5/django/db/models/lookups.py#L76

 I'm resolving the transform during the as_sql phase above which is wrong.
 But it was way too hard trying to track down all of the places that
 WhereNodes (and Lookups within the where node) were being rendered without
 first being resolved. Which is the very reason for this ticket.

 A WhereNode does not have to resolve to anything itself, but it has to
 give nested expressions the chance to resolve.

--
Ticket URL: <https://code.djangoproject.com/ticket/25425#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.0d3b4105dabfcbb229c3a004ee5d1a8f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to