#4102: Allow UPDATE of only specific fields in model.save()
-------------------------------------+-------------------------------------
Reporter: Collin Grady | Owner: cgrady
<cgrady@…> | Status: new
Type: New feature | Version: SVN
Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: update fields sql | Patch needs improvement: 1
row table modified | UI/UX: 0
Has patch: 1 |
Needs tests: 1 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by akaariai):
The patch looks good to me, I can't spot any serious failures there. Some
corner cases below. I would value other opinions on the issues below.
The patch still lacks the update_fields implies force_update=True part.
Does somebody know of a valid use case for "only fields" behavior for
inserts? My main concern here is that this breaks default values. Another
option (as is done in the patch) is to not imply force_update, but do full
save if the save leads to insert, so that the update_fields is in effect
only for updates. The documentation is currently misleading about the
behavior.
My take on this is to set force_update if update_fields is not None. There
are two main use cases for this feature: performance (in which case you do
want force_update=True), and "update only these fields, leave others as
they are in DB". In the latter case doing an insert would be an error. On
the other hand requiring the user to set the force_update=True is risk
free from Django's perspective.
Should datetime fields with auto_now=True be always included in the fields
list automatically?
If the update_fields is supplied but is empty shouldn't the save be
skipped completely in that case (or if it contains only the PK field)?
And still one more thing: the update_fields is passed to the signal
handler but its type is not known. If it happens to be a list (or any
other mutable container), the signal handler can modify it in place. There
is no safety checks for modifications done there. I am not sure if signal
handlers being able to modify the list is useful or not, but at least the
passed in type should be consistent: either a list or a tuple (actually,
set or immutable set could make more sense).
--
Ticket URL: <https://code.djangoproject.com/ticket/4102#comment:80>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
