#35014 closed Cleanup/optimization (wontfix)
update_or_create using update_fields opt out
Reported by: | Jordan Hyatt | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 4.2 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Prior to 4.2 update_or_create method did not use update_fields. That means developer's could count on the model save method being run and all fields being updated regardless of the defaults argument. After 4.2 only those fields passed to default will be updated. This presents a major breaking change especially for developers who rely heavily on save methods to populate fields. I believe there should be a parameter added to update_or_create that allows the user to opt out of using update_fields during save.
Attachments (1)
Change History (7)
comment:1 by , 11 months ago
Component: | Uncategorized → Database layer (models, ORM) |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
Type: | Uncategorized → Cleanup/optimization |
comment:2 by , 11 months ago
I just thought it would be nice and simple to add a "pass_update_fields=True" to update_or_create so that you can bypass the new behavior implemented that can have a huge effect on previously written code. You are right about catching the update_fields in the save, but there is no way to know if the save was called by update_or_create or not. What if sometimes I do want the update_fields to be used as is, just not when update_or_create was the source?
comment:3 by , 11 months ago
Also, in general, I don't think its a bad idea to have a little control over the way that update_or_create calls the save method. It's not overly complicated to give a little flexibility in that regard. This is a little out of scope of the original ticket. But wouldn't it be kind of neat if update_or_create could pass along additional kwargs to your custom save method? I know have plenty of use cases for that.
comment:4 by , 11 months ago
Resolution: | wontfix |
---|---|
Status: | closed → new |
comment:5 by , 11 months ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I appreciate you'd like to reopen the ticket, but please follow the triaging guidelines with regards to wontfix tickets and take this to DevelopersMailingList (or Django Forum) , where you'll reach a wider audience and see what other think.
But wouldn't it be kind of neat if update_or_create could pass along additional kwargs to your custom save method?
We don't add new options if it's not something useful for many folks.
I know I have plenty of use cases for that.
You didn't not present any specifics. Please be prepared to share concrete example in a forum/mailing list thread, if you will decide to start a discussion.
comment:6 by , 11 months ago
I have opened a forum topic where I posted a concrete use case. https://forum.djangoproject.com/t/update-or-create-behavior/25944
This is an intentional change mentioned in release notes.
I'm not sure how you use this. Are you talking about database triggers with some sophisticated behavior? If yes, then you can always pass all fields in
update_fields
or use triggers on rows (not particular column) update. I don't think it's worth additional complexity in Django itself.