由于旧迁移而发出警告 - 应该如何解决？
Warning because of old migration - how should that be solved?
如果我 运行 python -Wall manage.py test 出现此警告（和类似警告）：
/local/lib/python2.7/site-packages/django/db/models/fields/__init__.py:1453:
RuntimeWarning: DateTimeField SignUpUser.signup_time received a naive datetime (2018-03-17 21:27:22.620074) while time zone support is active.RuntimeWarning)
但是模型 SignUpUser 不再有这样的字段。它被称为signup_timestamp。其他字段也会出现同样的错误。为了解决这些问题，考虑到 timezone.now，我将 datetime.now 更改为 django 内置时区。但错误消息也不会消失。我认为这是因为旧的迁移。
该网站已经在制作中，但只有我在开发。我应该如何解决这个问题？重置所有迁移文件并使用 --fake-initial?
重做迁移
我运行陷入了类似的问题。我用 datetime.now 定义了 DateTimeField 的默认值并切换到 timezone.now。
我在每次模型更改后创建了迁移（可能是为了测试它们）。这导致一次迁移定义了没有时区的默认值 (field=models.DateTimeField(default=datetime.datetime(2018, 8, 2, 22, 15, 4, 702061)),)，而下一次迁移将解决此问题并添加时区 (field=models.DateTimeField(default=datetime.datetime(2018, 8, 3, 19, 22, 32, 951341, tzinfo=utc)),)。
当运行对模型 (python manage.py test app_name) 进行测试时，结果是：[...]/django/db/models/fields/__init__.py:1423: RuntimeWarning: DateTimeField Job.sub_date received a naive datetime (2018-08-02 22:15:04.702061) while time zone support is active.
Django 似乎试图将迁移应用于已定义时区感知的数据库。不知道为什么会那样做，但这似乎正在发生。
为了防止出现警告，我不得不将迁移压缩到将 DateTimeFiled 的默认值更改为时区感知的迁移。
在我的例子中，这是迁移 0007，而 0006 添加了没有时区感知的默认值。
所以创建南瓜的命令是：
$ python manage.py squashmigrations app_name 0007
这创建了一个新的迁移文件 0001_squashed_0007_auto_20180803_2122.py，其中包含迁移 0001 到 0007 所做的所有更改。正如 documentation 所说，这是以优化的方式发生的，因此只构建一系列迁移的最终结果而无需中间步骤。
在新安装中，不会 运行 单独迁移 0001 到 0007 只有新的压缩迁移 运行。
您应该将原始迁移保留一段时间，以确保压扁不会引入任何问题：
Once you’ve squashed your migration, you should then commit it alongside the migrations it replaces and distribute this change to all running instances of your application, making sure that they run migrate to store the change in their database.
You must then transition the squashed migration to a normal migration by:
- Deleting all the migration files it replaces.
- Updating all migrations that depend on the deleted migrations to depend on the squashed migration instead.
- Removing the replaces attribute in the Migration class of the squashed migration (this is how Django tells that it is a squashed migration).
如果我 运行 python -Wall manage.py test 出现此警告（和类似警告）：
/local/lib/python2.7/site-packages/django/db/models/fields/__init__.py:1453:
RuntimeWarning: DateTimeField SignUpUser.signup_time received a naive datetime (2018-03-17 21:27:22.620074) while time zone support is active.RuntimeWarning)
但是模型 SignUpUser 不再有这样的字段。它被称为signup_timestamp。其他字段也会出现同样的错误。为了解决这些问题，考虑到 timezone.now，我将 datetime.now 更改为 django 内置时区。但错误消息也不会消失。我认为这是因为旧的迁移。
该网站已经在制作中，但只有我在开发。我应该如何解决这个问题？重置所有迁移文件并使用 --fake-initial?
重做迁移我运行陷入了类似的问题。我用 datetime.now 定义了 DateTimeField 的默认值并切换到 timezone.now。
我在每次模型更改后创建了迁移（可能是为了测试它们）。这导致一次迁移定义了没有时区的默认值 (field=models.DateTimeField(default=datetime.datetime(2018, 8, 2, 22, 15, 4, 702061)),)，而下一次迁移将解决此问题并添加时区 (field=models.DateTimeField(default=datetime.datetime(2018, 8, 3, 19, 22, 32, 951341, tzinfo=utc)),)。
当运行对模型 (python manage.py test app_name) 进行测试时，结果是：[...]/django/db/models/fields/__init__.py:1423: RuntimeWarning: DateTimeField Job.sub_date received a naive datetime (2018-08-02 22:15:04.702061) while time zone support is active.
Django 似乎试图将迁移应用于已定义时区感知的数据库。不知道为什么会那样做，但这似乎正在发生。
为了防止出现警告，我不得不将迁移压缩到将 DateTimeFiled 的默认值更改为时区感知的迁移。
在我的例子中，这是迁移 0007，而 0006 添加了没有时区感知的默认值。
所以创建南瓜的命令是：
$ python manage.py squashmigrations app_name 0007
这创建了一个新的迁移文件 0001_squashed_0007_auto_20180803_2122.py，其中包含迁移 0001 到 0007 所做的所有更改。正如 documentation 所说，这是以优化的方式发生的，因此只构建一系列迁移的最终结果而无需中间步骤。
在新安装中，不会 运行 单独迁移 0001 到 0007 只有新的压缩迁移 运行。
您应该将原始迁移保留一段时间，以确保压扁不会引入任何问题：
Once you’ve squashed your migration, you should then commit it alongside the migrations it replaces and distribute this change to all running instances of your application, making sure that they run migrate to store the change in their database.
You must then transition the squashed migration to a normal migration by:
- Deleting all the migration files it replaces.
- Updating all migrations that depend on the deleted migrations to depend on the squashed migration instead.
- Removing the replaces attribute in the Migration class of the squashed migration (this is how Django tells that it is a squashed migration).