#33579: Raise a specialized exception when Model.save(update_fields) does not
affect any rows
-------------------------------------+-------------------------------------
     Reporter:  Simon Charette       |                    Owner:  Dulalet
         Type:  New feature          |                   Status:  assigned
    Component:  Database layer       |                  Version:  4.0
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:  Accepted
    Has patch:  1                    |      Needs documentation:  1
  Needs tests:  1                    |  Patch needs improvement:  1
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Comment (by Simon Charette):

 > I'd vote to remove it totally 😉, we don't raise any exception on save()
 without update_fields.

 As annoying as this exception can be I don't think we should entirely
 silence it. Passing `update_fields` is synonymous with `force_update` and
 just like when `force_insert` is provided erroring out to let callers know
 that the forced operation failed seems like the right thing to do as doing
 otherwise could result in unexpected data loses.

 At least with a specialized exception, something less generic than
 `DatabaseError`, callers can more adequately react to such errors. For
 example, raised `ObjectNotUpdated` can be turned into a 404, silenced, or
 turn into a subsequent `save` call without update fields depending on the
 situation.

 If you look at the ''core'' usages of `save(update_fields)` there seems to
 be cases where we'd want to do one over the other. For example,
 `reverse_many_to_one_manager._clear` might want to silence such exceptions
 
[https://github.com/django/django/blob/de1117ea8eabe0ee0aa048e5a4e249eab7c4245e/django/db/models/fields/related_descriptors.py#L909
 when assigning] `None` while in `RenameContentType._rename` you'd most
 like would want to refetch the row by natural key and update it again.

 Once the exception lands and is documented it could allow third party
 tools like DRF to catch them on `PUT` / `PATCH` and turn them into 404s.

 Given the patch has not been improved for over 6 months I'll assign it to
 me and try to bring it through the finish line.
-- 
Ticket URL: <https://code.djangoproject.com/ticket/33579#comment:14>
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/010701957a8e07ae-2e9d59bd-294f-4e85-b5f0-3797102e21cc-000000%40eu-central-1.amazonses.com.

Reply via email to