Changes between Initial Version and Version 1 of Ticket #33579, comment 14
- Timestamp:
- Mar 9, 2025, 6:09:51 AM (6 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #33579, comment 14
initial v1 1 1 > I'd vote to remove it totally 😉, we don't raise any exception on save() without update_fields. 2 2 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. 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. 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. 4 4 5 5 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.