# update\_or\_create Behavior

**URL:** <https://forum.djangoproject.com/t/update-or-create-behavior/25944>\
**Category:** ORM\
**Created:** [December 6, 2023, 1:17pm UTC](https://forum.djangoproject.com/t/update-or-create-behavior/25944 "2023-12-06T13:17:24Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![charettes](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/charettes/32/27_2.png) [@charettes](https://forum.djangoproject.com/u/charettes)\
**Post date:** [December 6, 2023, 8:11pm UTC](https://forum.djangoproject.com/t/update-or-create-behavior/25944/4 "2023-12-06T20:11:22Z")

</div>

> since they can no longer rely on save methods that automatically update derived fields to get saved because they wont be listed in update\_fields.

Aren’t such derived fields broken by design for any usage of `Model.save(update_fields)`?

Why can’t the `save` method of such models be adapted to augment `update_fields` with the dependant fields instead?

```python
def save(self, **options):
    if update_fields := options.get("update_fields"):
        options["update_fields"] = (
            set(update_fields)
            | self.get_derived_fields(update_fields)
        )
    return super().save(**options)

```

While I’m not convinced of its necessity I understand the reason why you’d want a `use_update_fields` flag to disable this new behaviour under some circumstances.

As for the `extra_save_kwargs` part of your proposed solution it has nothing do to with the problem discussed here. Django cannot support passing application specific flags to methods this way through a public interface.

---

_[View the full topic](https://forum.djangoproject.com/t/update-or-create-behavior/25944)._