[Django] #26984: Data Migrations and auto_now
Django
-----------------------------+--------------------
Reporter: fizista | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+--------------------
In the fields DateField and DateTimeField option auto_now during migration
puts me in confusion.
Normally, the data migration does not perform any external code that would
automatically modify data (for example, own method of "save").
However, it auto_now made during migration automatic changes in the data,
which seems to me not consistent with the idea of data migration.
During data migration there should be no any automatic changes to the
data, at least I think so.
So I proposed to remove action auto_now and / or auto_now_add during
migration.
--
Ticket URL: <https://code.djangoproject.com/ticket/26984>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: fizista | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by charettes):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Hi fizista,
I'm not sure I understand your request.
Using `auto_now` (just like any other `default` option) result in usage of
`DEFAULT` in `ADD FIELD` operations which is required when adding `NOT
NULL` fields (e.g. `DateTimeField(auto_now=True)`). What should be done
when such a column is added if we were to drop support for `default`
altogether?
--
Ticket URL: <https://code.djangoproject.com/ticket/26984#comment:1>
Django
Reporter: fizista | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by charettes):
Or maybe you are suggesting that `auto_now` and `auto_now_add` shouldn't
be effective in data migrations (e.g. `RunPython`?).
If that's the case I'm inclined to close this as ''wontfix'' since a lot
of efforts are made to make sure models provided in data migrations behave
exactly like normal models do.
--
Ticket URL: <https://code.djangoproject.com/ticket/26984#comment:2>
Django
Reporter: fizista | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by fizista):
Yes, I mean operations run in the "RunPython".
We can always use the "update_fields" in the method save.
--
Ticket URL: <https://code.djangoproject.com/ticket/26984#comment:3>
Django
Reporter: fizista | Owner: nobody
Type: New feature | Status: closed
Component: Migrations | Version: master
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by charettes):
* status: new => closed
* resolution: => wontfix
Comment:
I'll resolve as ''wontfix'' in this case as migrations were designed to
carry model state around in order to make models available through
`RunPython` operations behave just like normal models would at certain
point in a project.
I see no compelling reason to make `auto_now` or `auto_now_add` behave
differently when used in data migrations.
--
Ticket URL: <https://code.djangoproject.com/ticket/26984#comment:4>