Opened 13 months ago

Closed 13 months ago

Last modified 13 months ago

#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)

update_or_create.PNG (58.4 KB ) - added by Jordan Hyatt 13 months ago.
Suggested Changes

Download all attachments as: .zip

Change History (7)

comment:1 by Mariusz Felisiak, 13 months ago

Component: UncategorizedDatabase layer (models, ORM)
Resolution: wontfix
Status: newclosed
Type: UncategorizedCleanup/optimization

This is an intentional change mentioned in release notes.

That means developer's could count on the model save method being run and all fields being updated regardless of the defaults argument.

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.

comment:2 by Jordan Hyatt, 13 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 Jordan Hyatt, 13 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 I have plenty of use cases for that.

Last edited 13 months ago by Jordan Hyatt (previous) (diff)

by Jordan Hyatt, 13 months ago

Attachment: update_or_create.PNG added

Suggested Changes

comment:4 by Jordan Hyatt, 13 months ago

Resolution: wontfix
Status: closednew

comment:5 by Mariusz Felisiak, 13 months ago

Resolution: wontfix
Status: newclosed

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 Jordan Hyatt, 13 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

Note: See TracTickets for help on using tickets.
Back to Top