#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: 0
Keywords: update fields sql | Patch needs improvement: 1
row table modified | UI/UX: 0
Has patch: 1 |
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by akaariai):
* needs_docs: 1 => 0
* needs_tests: 1 => 0
Comment:
Replying to [comment:82 niwi]:
> 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.
Agreed. This is like qs.update() - no addition of auto_now fields there.
> 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.
I am not sure about this one. Main concern here is that removing a field
from update_fields can lead to implicit addition of all the model's fields
to the update_fields which feels counter-intuitive.
> 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?
The problem is if the user gives update_fields as a tuple then the signal
handler can not mutate it in place - if it is a set you can mutate it with
add - if it is a list then you can append to it. So, I am thinking of
converting the update_fields to a common type for the signal handler.
However not converting can be seen as a feature, too.
> I updated the documentation, but my English is not the best in the
world. If you can improve it, I would be very grateful.
I will see what I can do. The most important thing right now is having
somewhat correct information in correct places, not grammatical accuracy.
If I am not mistaken there are two open items:
1. Should empty, but not None update_fields argument skip save
completely instead of doing a normal save. My feeling is skip the save
here.
2. Should signal handlers be able to mutate the update_fields? It is
possible to leave this up to the caller of .save() - if a list was given
as update_fields, then it is mutable in the signal handler - if a tuple
was given then it isn't. Maybe leaving this as is (but checking that
isinstance(update_fields, (list, tuple))) is a good solution here.
I am leaving the "patch needs improvement" checked on grounds of not
actually testing the patch...
--
Ticket URL: <https://code.djangoproject.com/ticket/4102#comment:83>
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.
