#34099: update_or_create() not saving data assigned in a model's save() method
-------------------------------------+-------------------------------------
Reporter: Phil Gyford | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: dev
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Florian Apolloner):
> I agree with Simon, we should revert the commit and closed #32095 as
"wontfix".
I also agree with Simon but am not really convinced we should revert the
commit. I agree that the docs are somewhat unfortunate in the sense that
the boiler plate code does not use `update_fields` to only update fields
from `defaults`. But aside from that nothing in `update_or_create` suggest
that all fields would (or should) get saved. It actually says:
> The defaults is a dictionary of (field, value) pairs used to update the
object.
This could in the end also be done via `qs.update()` instead of
`qs.save()`. So the main question becomes: Is the behavior that people
relied on an implementation detail on which the relied erroneously? Can we
deal with the fallout? If the answer to the latter is no, can we somehow
salvage this situation? Using `update_fields` is really preferred
especially in cases with concurrent access.
--
Ticket URL: <https://code.djangoproject.com/ticket/34099#comment:7>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/01070183e65ab888-7a7367a4-c337-4842-89fc-4690ce96e877-000000%40eu-central-1.amazonses.com.
