#15566: .update queries should affect Date*Field's with auto_now
-------------------------------+------------------------------------
Reporter: jdunck | Owner: bberes
Type: Bug | Status: assigned
Component: Documentation | Version: 1.2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by russellm):
Replying to [comment:15 anonymous]:
> If {{{Queryset.update}}} is a lower-level SQL construct, then why do we
have {{{cursor.execute}}} which could achieve the same thing in almost the
same amount of SLOC and still remain perfectly
[https://docs.djangoproject.com/en/dev/topics/db/sql/#passing-parameters-
into-raw injection-proof]?
Because .update() is database agnostic; raw SQL isn't necessarily cross-
database compatible. I'd also argue that the syntax for something like a
simple field value increment is cleaner in the ORM than in raw SQL,
especially for a codebase that is principally written in ORM syntax.
> {{{Queryset.update}}} is used widely in most of the apps I've worked on,
and I'm pretty certain the developers who've added it didn't think of it
as a low-level tool, but rather just an ORM method for updating multiple
rows at the same time without having to select each and save each
separately (ie, a simply efficiency tool in the ORM).
I can't speak to how the method is perceived in the wild -- that's a
documentation issue -- but a quick inspection of the implementation of the
parts involved points pretty quickly to the fact that it can't be
interpreted as anything *but* a low level method.
auto_now_add is implemented as a pre-save, per-field modification. The
fact that the value for this modification is easily evaluated, and the
value for the field will be the same for all rows in the update is
convenient, but doesn't solve the underlying issue -- that what we're
dealing with is a field value that is computed on a per-row basis.
To point out the underlying problem - consider another type of field with
a pre-save trigger; say, a CharField whose value is a computed checksum
based on other fields and the timestamp. There's no way this could be
expressed as a single update statement for multi-row updates.
The only way you could reconcile this with auto_now_add being fired on
.update() is to consider the handling of auto_now_add to be a special case
because it is a timestamp. I'm not convinced that special case is special
enough to warrant breaking the rules.
> To show I'm not just ranting, I'll be willing to write the necessary
patch and corresponding tests with some guidance on how to handle both the
aforementioned cases.
If you can provide a patch that works for pre-save updates *in the general
case*, then I'm interested. Otherwise, what you're proposing is to make a
special case of date and time fields, and that's not something I'm
comfortable with.
I concur with Luke and Anssi; this is a documentation issue regarding the
limitations and expectations of a call to .update().
--
Ticket URL: <https://code.djangoproject.com/ticket/15566#comment:16>
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.
