#22995: Deprecate auto_now and auto_now_add and document alternatives
-------------------------------------+-------------------------------------
Reporter: Jannis Leidel | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Someday/Maybe
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Melvyn Sopacua):
This issue was recently brought up again on django-users and I'd like to
propose a different path.
There are three issues to consider:
1. The initial design thought was that these fields are immutable, from
the application perspective and should be used for auditing. In real life,
auto_now_add is used as a default and expectation is that it should be
mutable. For auto_now this distinction only a systematic concern, but
should not impact real world scenario's beyond the microsecond scope.
2. The implementation has bugs that in certain scenario's they do not do
their job. While documented, this is still a bug.
3. Setting `editable` to False does not prevent setting values for the
field. It only does so for model forms.
== FIxing auto_now_add
To make transition easier, we could implement a keyword `auto_now` that
can be used as argument to `default`. What this does is up for debate. IMO
every supported database can use some form of `DEFAULT CURRENT_TIMESTAMP`,
so if we move implementation to the database layer, this can be wrapped as
a default argument at table creation. This would also fix any issues with
it not being set under certain circumstances.
It could also be a callback, that does the same work as auto_now_add does
now, including the timezone imports etc. It would also fix the
implementation bug and it would be consistent with any timezone
configuration within Django, while setting a default at the database layer
would set the default to whatever the database layer thinks is correct.
Probably the best fix overall would be to enforce UTC at the database
layer and do all interpretation in Django, but that's beyond the scope of
this ticket.
== The immutable fields
Instead of naming them ambiguous again, I think the replacements for this
functionality should be prefixed with `Auto`, so for example
`AutoLastModifiedField`. This should be ample hint to the implementer that
all the work is done for her and she can't touch it. It also allows for a
LastModifiedField that can be overridden by forms. A use case would be
formatting changes to a wiki document - it would not constitute a document
change, so one could preserve the original value.
== Fixing the implementation
I'm all for moving all implementations (so the auto fields and auto_now
default) to the database layer, but that requires some thought and
perspective. Why was it originally chosen to do this in python?
== Not editable but changeable
So even when the auto_now keywords are marked not editable, they are still
not conforming to the original design thought for auditing purposes. A
value can still be set and saved. Is this intentional and does the
original reasoning still apply?
--
Ticket URL: <https://code.djangoproject.com/ticket/22995#comment:17>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.0817a0754d4439515df4c6f388f8b06e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
