#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 niwi):
Replying to [comment:80 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.
[[BR]]
I've been thinking about this and I think you're right! ``update_fields``
have to implies ``force_update=True``. Although, I agree considerations!
[[BR]]
>
> 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?
[[BR]]
At this point, I think we should not automatically preselected fields
"DateTimeField" with "auto_now = True". This option is for advanced use,
and in this case one must know what is really saving.
[[BR]]
>
> 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)?
[[BR]]
If the update_fields is supplied but is empty, now, will have the same
behavior when update_fields is not supplied. In my opinion the behavior is
correct.
[[BR]]
>
> 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).
[[BR]]
I think it should be a mutable object. Thus, if someone needs it, will
have the ability to automatically add to the list datetime fields with
auto_now = True.
I do not understand what you mean by specifying the type. If the parameter
is None, the signal receives None. If the parameter list/tuple, the signal
receives list/tuple.
Are you thinking about some kind of type checking?
[[BR]]
>
> EDIT: Just noted that there is .delete() calls in the end of the test
methods: no need for that, Django's TestCase will do the cleanup for you.
[[BR]]
I updated the documentation, but my English is not the best in the world.
If you can improve it, I would be very grateful.
--
Ticket URL: <https://code.djangoproject.com/ticket/4102#comment:82>
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.
