#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 django-updates@googlegroups.com. To unsubscribe from this group, send email to django-updates+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-updates?hl=en.