【问题标题】:Django migration stuckDjango迁移卡住了
【发布时间】:2015-10-16 20:52:35
【问题描述】:

我有一个新字段要添加到我的数据库中。所以我说

python manage.py makemigrations

正确创建kernel/migrations/0003_auto_20150726_1911.py。我检查了内容,一切看起来都很好。

我说

python manage.py migrate

我不那么高兴了。将字段 date_of_birth 添加到表 userprofile 的文件 kernel/migrations/0002_auto_20150707_1459.py 失败。即使我很确定应用了迁移。因此永远不会应用迁移 0003。

这是生产。 :( 我完全不知道该怎么做才能应用 0003 而不是软管 django。有什么建议吗?

剩下的就是支持文档:

迁移

╭╴ (master=) [virt]╶╮
╰ [T] django@beta13:migrations $ cat 0002_auto_20150707_1459.py 
# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models, migrations


class Migration(migrations.Migration):

dependencies = [
    ('kernel', '0001_initial'),
]

operations = [
    migrations.AlterField(
    model_name='userprofile',
    name='date_of_birth',
    field=models.DateField(null=True, blank=True),
    ),
]
╭╴ (master=) [virt]╶╮
╰ [T] django@beta13:migrations $ cat 0003_auto_20150726_1911.py 
# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models, migrations
from django.conf import settings


class Migration(migrations.Migration):

dependencies = [
    migrations.swappable_dependency(settings.AUTH_USER_MODEL),
    ('kernel', '0002_auto_20150707_1459'),
]

operations = [
    migrations.AddField(
    model_name='trippending',
    name='requesting_user',
    field=models.ForeignKey(default=1, related_name='trippending_requesting', to=settings.AUTH_USER_MODEL),
    preserve_default=False,
    ),
    migrations.AddField(
    model_name='userprofile',
    name='can_see_pending_trips',
    field=models.BooleanField(default=False),
    ),
]
╭╴ (master=) [virt]╶╮
╰ [T] django@beta13:migrations $ 

错误

(该网站以法语运行,但我认为错误很明显。)

╭╴ (master %=) [virt]╶╮
╰ [T] django@beta13:django $ python manage.py migrate
Operations to perform:
  Synchronize unmigrated apps: staticfiles, messages, admindocs
  Apply all migrations: admin, sessions, custom_user, auth, kernel, contenttypes, registration, sites
Synchronizing apps without migrations:
  Creating tables...
Running deferred SQL...
  Installing custom SQL...
Running migrations:
  Rendering model states... DONE
  Applying kernel.0002_auto_20150707_1459...Traceback (most recent call last):
  File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
  File "/src/django/venv/lib/python3.4/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
utility.execute()
  File "/src/django/venv/lib/python3.4/site-packages/django/core/management/__init__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/src/django/venv/lib/python3.4/site-packages/django/core/management/base.py", line 390, in run_from_argv
self.execute(*args, **cmd_options)
  File "/src/django/venv/lib/python3.4/site-packages/django/core/management/base.py", line 441, in execute
output = self.handle(*args, **options)
  File "/src/django/venv/lib/python3.4/site-packages/django/core/management/commands/migrate.py", line 221, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
  File "/src/django/venv/lib/python3.4/site-packages/django/db/migrations/executor.py", line 110, in migrate
self.apply_migration(states[migration], migration, fake=fake, fake_initial=fake_initial)
  File "/src/django/venv/lib/python3.4/site-packages/django/db/migrations/executor.py", line 147, in apply_migration
state = migration.apply(state, schema_editor)
  File "/src/django/venv/lib/python3.4/site-packages/django/db/migrations/migration.py", line 115, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
  File "/src/django/venv/lib/python3.4/site-packages/django/db/migrations/operations/fields.py", line 201, in database_forwards
schema_editor.alter_field(from_model, from_field, to_field)
  File "/src/django/venv/lib/python3.4/site-packages/django/db/backends/base/schema.py", line 484, in alter_field
old_db_params, new_db_params, strict)
  File "/src/django/venv/lib/python3.4/site-packages/django/db/backends/base/schema.py", line 571, in _alter_field
old_default = self.effective_default(old_field)
  File "/src/django/venv/lib/python3.4/site-packages/django/db/backends/base/schema.py", line 211, in effective_default
default = field.get_db_prep_save(default, self.connection)
  File "/src/django/venv/lib/python3.4/site-packages/django/db/models/fields/__init__.py", line 710, in get_db_prep_save
prepared=False)
  File "/src/django/venv/lib/python3.4/site-packages/django/db/models/fields/__init__.py", line 1322, in get_db_prep_value
value = self.get_prep_value(value)
  File "/src/django/venv/lib/python3.4/site-packages/django/db/models/fields/__init__.py", line 1317, in get_prep_value
return self.to_python(value)
  File "/src/django/venv/lib/python3.4/site-packages/django/db/models/fields/__init__.py", line 1287, in to_python
params={'value': value},
django.core.exceptions.ValidationError: ["Le format de date de la valeur «\xa0\xa0» n'est pas valide. Le format correct est AAAA-MM-JJ."]
╭╴ (master %=) [virt]╶╮
╰ 1,[T] django@beta13:django $ 

数据

我检查了 postgres,希望能发现一些不对劲的地方。但一切看起来都很好。

mydb=# select date_of_birth from kernel_userprofile;
 date_of_birth 
---------------
 2018-10-23
 1972-05-31
 1978-10-21
 2008-12-29
 1967-08-26
 2015-07-26
(6 rows)

mydb=#

【问题讨论】:

  • 迁移表是不是有些人弄乱了?通常这种情况发生在 0002 迁移的迁移行从数据库中删除时,你能检查一下吗?另外我认为堆栈跟踪不完整,您能否完成它以进一步提供帮助。
  • 我认为没有人对此感到厌烦。如何检查迁移表?我在 postgres 中看不到可能的候选人。
  • 堆栈跟踪从我的提示符运行到我的下一个提示符。我很确定所有的干预线都存在。似乎缺少什么?
  • 如果您使用的是 Django 1.7 而不是南,通常是 django_migrations。
  • 3;"auth";"0001_initial";"2015-07-22 10:18:57.612555+05:30" 表中的迁移数据将如下所示。将根据上次迁移选择下一个迁移。

标签: django postgresql django-models django-south


【解决方案1】:

对于社区来说,问题是django_migrations 表没有更新为0002_auto_20150707_1459,即使迁移实际上是在帖子中提到的table 上应用的。

解决方案是在django_migrations 表中插入一个新行,其中包含如下数据,因此跳过了迁移0002

INSERT INTO DJANGO_MGRATIONS ('app', 'name', 'applied') VALUES ('appname', '0002_auto_20150707_1459', '2015-07-07 00:00')

跳过迁移必须非常小心,因此在跳过之前检查所有详细信息。

【讨论】:

    【解决方案2】:

    同样的问题发生了,但没有任何日志

    1. 起初我通过运行确定是哪个应用程序出现问题
    python manage.py migrate app_name
    

    对于每个django 应用程序

    1. 之后我通过运行检查应用程序的迁移
    python manage.py showmigrations app_name
    
    1. 并通过运行将第一个未完成的迁移标记为已完成
    python manage.py migrate --fake app_name migration_name
    

    ※ about fake

    这就是我的解决方案

    【讨论】:

      【解决方案3】:

      对于任何发现这篇文章的人:我刚刚帮助同事调试了一个类似的问题(相同的错误消息),在这种情况下,问题的根源是试图给 DateField 一个默认值u""(它是当然对日期无效)而不是None

      实际上部分乐趣在于之前的迁移(创建模型)已经有这个错误的默认值,但仍然可以无缝运行,该错误仅在尝试以任何方式更改字段时出现。

      修复需要编辑 previous 迁移以设置合理的默认值,因为 Django 使用之前迁移的架构描述来获取之前的默认值。

      【讨论】:

        猜你喜欢
        • 2018-03-12
        • 1970-01-01
        • 1970-01-01
        • 2019-02-13
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2016-06-22
        相关资源
        最近更新 更多