Data Migrations and auto_now

[Wojciech Banaś]

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.

[Simon Charette]

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?

[Simon Charette]

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.

[Wojciech Banaś]

Yes, I mean operations run in the "RunPython".
We can always use the "update_fields" in the method save.

[Simon Charette]

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.