Changes between Initial Version and Version 1 of Ticket #34099, comment 10
- Timestamp:
- Oct 27, 2022, 1:27:35 PM (2 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #34099, comment 10
initial v1 5 5 For example, when partially fetching model instance fields (e.g. using `only`) then [https://github.com/django/django/blob/de2c2127b66e77a034c01c81753c5c08e651a5b4/django/db/models/base.py#L793-L802 only the fetched fields will be updated] which [https://docs.djangoproject.com/en/4.1/ref/models/querysets/#django.db.models.query.QuerySet.defer is documented]. 6 6 7 If we believe that documenting how to properly override `Model.save` or deal with `post_save` signal wrt/ to `update_fields` is not enough the only deprecation path I can think of that doesn't involve adding a setting is to add a temporary `__save_update_fields=False` kwarg to `update_or_create` and when `__save_update_fields is False` and `save() ` is overridden or `post_save` signals are connected emit a deprecation warning and don't pass `update_fields`. That would allow callers to pass `__save_update_fields=True` to opt-in the new behaviour and silence the warning .7 If we believe that documenting how to properly override `Model.save` or deal with `post_save` signal wrt/ to `update_fields` is not enough the only deprecation path I can think of that doesn't involve adding a setting is to add a temporary `__save_update_fields=False` kwarg to `update_or_create` and when `__save_update_fields is False` and `save() ` is overridden or `post_save` signals are connected emit a deprecation warning and don't pass `update_fields`. That would allow callers to pass `__save_update_fields=True` to opt-in the new behaviour and silence the warning during the deprecation period. 8 8 9 9 This all seems like a lot of work for little benefit to me though given we didn't take this extra precautions when introducing `update_fields` in the first place in Django 1.5 and code that fails to account for this feature has been subtly broken since then.