#33579: Raise a specialized exception when Model.save(update_fields) does not
affect any rows
-------------------------------------+-------------------------------------
Reporter: Simon Charette | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(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
-------------------------------------+-------------------------------------
Description changed by Simon Charette:
Old description:
> When `Model.save(update_fields)` is used to update an instance of a
> previously fetched model and the resulting `UPDATE` doesn't affect any
> row a `DatabaseError`
> [https://github.com/django/django/blob/3b3f38b3b09b0f2373e51406ecb8c9c45d36aebc/django/db/models/base.py#L1000
> is raised].
>
> Since the resulting exception cannot be differentiated by its `type` from
> any other exception raised during `save` (e.g. a failed `UPDATE` also
> results in a `DatabaseError`) the only pattern to gracefully handle this
> rare edge case to catch all `DatabaseError` and compare its `.args[0]`
> (or `str` representation) to a string that doesn't offer any stability
> guarantees.
>
> In order to make it easier for advanced users that rely on the
> `update_fields` feature to handle this case differently from others where
> a `DatabaseError` is raised I propose that that we introduced a new
> `DatabaseError` subclass that would be raised instead when an unexpected
> empty update occurs.
>
> I believe
> [https://github.com/django/django/blob/3b3f38b3b09b0f2373e51406ecb8c9c45d36aebc/django/db/models/base.py#L997-L1000
> both instances] should be switched to this pattern (`force_update` and
> `update_fields`).
New description:
When `Model.save(update_fields)` is used to update an instance of a
previously fetched model and the resulting `UPDATE` doesn't affect any row
a `DatabaseError`
[https://github.com/django/django/blob/3b3f38b3b09b0f2373e51406ecb8c9c45d36aebc/django/db/models/base.py#L1000
is raised].
Since the resulting exception cannot be differentiated by its `type` from
any other dababase errors occuring during `save` (e.g. a failed `UPDATE`
also results in a `DatabaseError`) the only pattern to gracefully handle
this rare edge case to catch all `DatabaseError` and compare its
`.args[0]` (or `str` representation) to a string that doesn't offer any
stability guarantees.
In order to make it easier for advanced users that rely on the
`update_fields` feature to handle this case differently from others where
a `DatabaseError` is raised I propose that that we introduce a new
`DatabaseError` subclass that would be raised instead when an unexpected
empty update occurs.
I believe
[https://github.com/django/django/blob/3b3f38b3b09b0f2373e51406ecb8c9c45d36aebc/django/db/models/base.py#L997-L1000
both instances] should be switched to this pattern (`force_update` and
`update_fields`).
--
--
Ticket URL: <https://code.djangoproject.com/ticket/33579#comment:1>
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 on the web visit
https://groups.google.com/d/msgid/django-updates/0107017f8f9e6ed7-d53123de-c35c-4fcc-81dc-588aac12d767-000000%40eu-central-1.amazonses.com.
