# update\_or\_create(defaults=None) sends update\_fields=set() rather than None **URL:** https://forum.djangoproject.com/t/update-or-create-defaults-none-sends-update-fields-set-rather-than-none/41657 **Category:** ORM **Created:** [July 2, 2025, 3:34pm UTC](https://forum.djangoproject.com/t/update-or-create-defaults-none-sends-update-fields-set-rather-than-none/41657 "2025-07-02T15:34:17Z") **Posts on this page:** 1 **Showing post:** 3
### Author: ![jacobtylerwalls](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/jacobtylerwalls/32/30603_2.png) [@jacobtylerwalls](https://forum.djangoproject.com/u/jacobtylerwalls) #### Post date: [July 2, 2025, 9:18pm UTC](https://forum.djangoproject.com/t/update-or-create-defaults-none-sends-update-fields-set-rather-than-none/41657/3 "2025-07-02T21:18:16Z")
Thanks for having a look! > [@charettes](#): > > Hard to tell without an exact test case but is there a reason why you compute `baz` and assign it if it’s not meant to be persisted? It is meant to be persisted. I noticed today I wasn’t handling the case where it shouldn’t be persisted correctly (the empty iterable case). Here’s a [fiddle](https://dryorm.xterm.info/update-or-create-update-fields) with what I mean. > If there are no fields to update no save should take place so it could even be argued that `save` should not be called at all when `update_fields` is empty I guess that’s my question – `create()` delegates to `save()` without requiring knowledge of whatever fields `save()` manages itself. But `update_or_create()` _does_ require this knowledge post ticket-32095. > I’m pretty confident we can’t change `update_or_create` to pass `update_fields or None` without defeating the purpose Ah, right, of course. I guess my choices are: - bite bullet: decouple cleaning from save - bite bullet: factor recalculations out of save methods into custom fields with `pre_save()` implemented - hack: audit all `update_or_create()` usage to impart knowledge of the fields that `save()` manages itself (not future-proof) - hack: continue mishandling empty iterables for `update_fields` in general, but define a custom empty iterable I can sniff for when it’s important to handle it correctly (i.e. when I truly want no fields to be updated) 1 is a huge lift. 2 would grow the number of custom fields more than I’d like. 3 doesn’t sound right. I’ll probably opt for 4, although it’s not strictly correct. I was just checking my understanding before going down that path. --- _[View the full topic](https://forum.djangoproject.com/t/update-or-create-defaults-none-sends-update-fields-set-rather-than-none/41657)._