#33091: A FieldError should be raised when trying to update MTI inherited field
with F reference to child field
-------------------------------------+-------------------------------------
     Reporter:  Shai Berger          |                    Owner:  Clifford
         Type:                       |  Gama
  Cleanup/optimization               |                   Status:  assigned
    Component:  Database layer       |                  Version:  dev
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:  Accepted
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Comment (by Shai Berger):

 Replying to [comment:10 Clifford Gama]:
 > {{{#!diff
 > diff --git a/django/db/models/sql/subqueries.py
 b/django/db/models/sql/subqueries.py
 > index 9cb971b38f..7f6d06ee1f 100644
 > --- a/django/db/models/sql/subqueries.py
 > +++ b/django/db/models/sql/subqueries.py
 > @@ -99,6 +99,12 @@ class UpdateQuery(Query):
 >                      "Cannot update model field %r (only non-relations
 and "
 >                      "foreign keys permitted)." % field
 >                  )
 > +            for field_name, *lookups in
 model._get_expr_references(val):
 > +                if field_name not in
 model._meta._local_concrete_field_names:
 > +                    raise FieldError(
 > +                        "Cannot update model field %r using the non-
 local field "
 > +                        "reference %r." % (field, field_name)
 > +                    )
 >              if model is not self.get_meta().concrete_model:
 >                  self.add_related_update(model, field, val)
 >                  continue
 > }}}

 I find the language "non-local field reference" a bit cryptic. It's only
 clear when you think in terms of {{{_meta}}} properties and functions, and
 it's too easy to code the error when not thinking about those at all.

 It makes sense to me, to use something like your suggestion to easily find
 if there was an error. But in the case that an error is found, I'd prefer
 if we start looking for the specific cases, so we can give a more friendly
 error message.
-- 
Ticket URL: <https://code.djangoproject.com/ticket/33091#comment:12>
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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/django-updates/01070195f27f419b-7429af84-b45e-407b-85a8-78e17b879545-000000%40eu-central-1.amazonses.com.

Reply via email to