Changes between Initial Version and Version 1 of Ticket #33579, comment 14


Ignore:
Timestamp:
Mar 9, 2025, 6:09:51 AM (6 months ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #33579, comment 14

    initial v1  
    11> I'd vote to remove it totally 😉, we don't raise any exception on save() without update_fields.
    22
    3 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.
     3As 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. Any `save()` call can raise an `IntegrityError` (and other flavors of `DatabaseError`) so even if we removed that particular instance it would still be best practice to handle them on `save` calls.
    44
    55At 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.
Back to Top