Isn’t that alarming to you? If you have that many fields that adapting their model’s save method represents a large a mount of work how can you be certain that there isn’t some code in your large code base (or one of your third party app) that is calling the bogus SomeModel.save(update_fields) which might break your code in subtle ways?
Under certain conditions yes. The signature must remain compatible and the override must be able to deal with the overridden version’s optional kwargs in a way that preserves the semantic of the option.
Your request to allow passing extra_save_kwargs is. While Python allows you to override methods, Django cannot build and maintain the large surface area of its high level abstractions in a way that systematically allows application level specific kwargs to percolate towards the lower ones it relies on. The bar for such percolation mechanism is quite high and IMO this feature request does not meet it as the fact save is called here is an implementation detail of update_or_create.
Think of it this way: what makes update_or_create special over get_or_create, which also calls save, that it warrants the addition of a pass through of save kwargs and not the other?
And what does it have to do with passing or not update_fields to save which the crux of the issue you’re reporting to face here?
I’m not sure I’m following you here. If you need to pass a single bypass flag then it means you have a single update_or_create call, then it means you have a single model affected and thus a single Model.save method to adapt to make sure to augment update_fields with the derived fields.