例外。不一致的迁移历史

如果该异常在您试图创建自己的用户模型而不是标准模型时显示出来，请遵循 指示
我发现我的问题解决了，按照指示一步一步来:

1. 创建一个与 auth 相同的自定义用户模型 多对多表保持相同的名称) ，并设置 db _ table = ‘ auth _ user’ (因此它使用相同的表)
2. 扔掉你所有的迁徙
3. 重新创建一组新的迁移
4. 牺牲一只鸡，如果您感到焦虑，可以牺牲两只; 还要备份数据库
5. 截断 django _ mobilations 表
6. 伪造-应用新的迁移集
7. 取消 db _ table 设置，对自定义模型进行其他更改，生成迁移并应用它们

强烈建议在执行 外键约束。不要在笔记本电脑上的 SQLite 上尝试 希望它对服务器上的 Postgres 有效！

问题

例外情况。不一致的迁移历史: 迁移 admin.0001 _ first 应用于数据库‘ default’上的依赖帐户之前。

因此，我们可以迁移数据库没有管理员(admin.0001 _ first)第一。

迁移依赖项之后，执行命令迁移 admin.0001_initial。

解决方案

1. 在 setings.py 中从 INSTALLED _ APPS 中删除‘ django.Contrib.admin’。
2. 执行命令:

Py make 移民应用程序名称

Py 迁移应用程序名称

3. 在 setings.py 文件中向 INSTALLED _ APPS 添加‘ django.Contrib.admin’。
4. 再次执行命令:

Py make 移民应用程序名称

Py 迁移应用程序名称

如果像这样在 设置中设置 AUTH _ USER _ MODEL:

AUTH_USER_MODEL = 'custom_user_app_name.User'

在运行 移民和 迁徙命令之前，您应该注释这一行。然后您可以再次取消注释这一行。

只需删除 sqlite 文件或者运行刷新数据库‘ python management. py rush’ 然后分别运行 make 迁移和 shift 命令。

当您创建一个没有应用程序的新项目时，可以运行

python manage.py migrate

默认情况下，Django 将创建10个表。

如果您希望创建一个继承自 AbstractUser的客户用户模型，那么您将遇到以下问题:

异常。不一致的迁移历史: 迁移 admin.0001 _ first 在其依赖项之前应用 在数据库‘ default’上初始化 account t.0001 _ initialon。

最后, 我丢下我所有的数据库跑了

当您创建一个新的 Django 项目并运行

Python management

默认情况下，Django 将为您创建10个表，包括一个 auth _ user 表和两个以 auth _ user 开头的表。

当您希望创建从 AbstractUser 继承的自定义用户模型时，您将遇到如下错误消息:

django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'.

我通过删除整个数据库并创建一个新数据库来解决这个问题。这个取代了我提到的三张桌子。

我在从 Wagtail 2.0迁移到2.4的过程中遇到过这种情况，但是在你要迁移到的版本之前，第三方应用程序挤压了你当前版本的迁移 之后时，我也遇到过几次这种情况。

至少在这种情况下，令人震惊的简单解决方案是:

./manage.py migrate
./manage.py makemigrations
./manage.py migrate

也就是说，在尝试移民之前进行一次迁移。

除了用户错误之外，还有另一个可能导致这种问题的原因: 当涉及到压缩迁移时，姜戈的一个众所周知的问题。

我们有一系列的迁移，在 Python 2.7 + Django 1.11中可以很好地工作。运行 makemigrations或 migrate总是按照它应该的方式工作，等等，甚至(为了测试的目的)在数据库刚刚重新创建时也是如此。

然而，当我们将一个项目迁移到 Python 3.6(目前使用相同的 Django 1.11)时，我一直在试图弄清楚为什么相同的迁移只在第一次运行时才能很好地应用。在此之后，任何运行 makemigrations或甚至仅仅运行 migrate的尝试都会导致错误:

django.db.migrations.exceptions.InconsistentMigrationHistory

其中迁移 foo.0040-thing是在依赖 foo.0038-something-squashed-0039-somethingelse之前应用的(我们只碰巧有一个被压缩的迁移... ... 其余的要简单得多)。

困扰我一段时间的是为什么这只发生在 Python 3上。如果数据库真的不一致，这种情况应该一直发生。第一次应用这些迁移时，它们似乎完全可以正常工作，这同样令人困惑。

经过大量的搜索(包括目前的问答线程) ，我偶然发现了 刚才提到的姜戈窃听器报告。我们的南瓜迁移确实在 replaces行中使用了 b前缀(例如，replaces = [(b'', 'foo.0038-defunct'),.......])

一旦我从 replaces行删除了 b前缀，它就正常工作了。

您的错误基本上是:

Migration "B" is applied before its dependency "A" on database 'default'.

Sanity Check : 首先，打开数据库并查看“ django _ ”表中的記錄。记录应按时间顺序列出(如: A，B，C，D。.).

确保错误中列出的“ A”迁移的名称与数据库中列出的“ A”迁移的名称相匹配。(如果您以前手动、编辑或删除或重命名了迁移文件，它们可能会有所不同)

要修复 This ，请在数据库中重命名迁移 A 或重命名文件名。但是要确保更改与团队中其他开发人员在其数据库中的数据相匹配(或者更改与生产数据库中的数据相匹配)

如果在初始迁移之后扩展用户模型，这个问题在大多数情况下都会出现。因为无论何时你扩展抽象用户，它都会创建基本的字段，这些字段在模型中是存在的，比如 email，first _ name 等等。

甚至这也适用于 django 中的任何抽象模型。

因此，一个非常简单的解决方案是要么创建一个新数据库，然后应用迁移，要么删除 [在这种情况下，您的所有数据都将被删除。]同一个数据库，然后重新应用迁移。

如果您正在处理一个空数据库，那么在进行任何其他应用程序迁移之前，可以对 帐户应用程序的迁移进行快速修复。

$ ./manage.py migrate account

然后:

$ ./manage.py migrate

在一个新项目中，我按照 django 文档中的建议添加了一个自定义 User 模型，就发生了这种情况。

如果您正在开始一个新项目，强烈建议您设置一个自定义用户模型，即使默认的 User 模型对您来说已经足够了。

以下是我为解决这个问题所做的工作。

1. 删除数据库 db.sqlite3。
2. 删除应用程序/迁移文件夹。

Per@jackson，暂时注释掉 django.Contrib.admin。

INSTALLED_APPS = [
...
#‘django.contrib.admin’,
...
]

还要在 urls.py 中注释掉管理站点:

urlpatterns = [
path('profile/', include('restapp.urls')),
#path('admin/', admin.site.urls),
]

如果没有注释掉路径(‘ admin/’) ，那么在运行时会得到错误“ LookupError: No installatedapp with label‘ admin’”

python manage.py migrate

在完成迁移之后，取消上述两者的注释。

通过在 setings.py 中迁移之前注释应用程序 管理员解决了这个问题

django.contrib.admin

还有 urls.py,

('admin/', admin.site.urls)

迁移后取消注释

首先备份你的数据。(复制你的数据库文件)。

删除 sqlite.db 和迁移文件夹 。

然后，运行以下命令:

./manage.py makemigrations APP_NAME
./manage.py migrate APP_NAME

删除 DB 文件和迁移文件夹后，请确保在迁移命令之后写入应用程序名称。

好吧，在你做任何奇怪的或核动力的事情之前，先放下你的数据库，重建它。

如果使用 POsgres-

DROP SCHEMA public CASCADE;
CREATE SCHEMA PUBLIC;

那就重新进行迁移

./manage.py migrate

这是最基本的解决方案，通常会把事情弄清楚。在绝对必要之前，不要只是重新进行迁移。

在执行任何其他步骤之前，先备份数据库，然后再次备份。

删除任何自定义用户模型代码，在设置中禁用自定义模型和应用程序，然后:

python manage.py dumpdata auth --natural-primary --natural-foreign > auth.json
python manage.py migrate auth zero  # This will also revert out the admin migrations

然后添加您的自定义模型，在设置中设置它，并重新启用应用程序。确保你还没有在这个应用程序上进行迁移。

然后:

python manage.py makemigrations <your-app>
python manage.py migrate
python manage.py loaddata auth.json  # Assumes your user-model isn't TOO dissimilar to the standard one.

成交！

我必须放下我的数据库，然后运行 mak 移民，并再次迁移，以便解决这个问题。

删除迁移文件夹和 db.sqlite3并键入 cmd Python management. py makhemations

INSTALLED_APPS的顺序似乎很重要。 如果你总是把你最近的作品放在列表的顶部/开头，那么它们总是会被正确地加载到 django.Contrib.admin 中。把我的作品移到 INSTALLED_APPS列表的开头为我解决了这个问题。 昆氏的解决方案可能有效的原因可能是它以不同的顺序运行迁移。

异常。不一致的迁移历史 # 关于创建自定义用户模型

今天我遇到了同样的问题，上面的解决方案都不管用，然后我想用下面的命令擦除本地 PostgreSQL 数据库中的所有数据

-- Drop everything from the PostgreSQL database.


DO $$
DECLARE
q TEXT;
r RECORD;
BEGIN
-- triggers
FOR r IN (SELECT pns.nspname, pc.relname, pt.tgname
FROM pg_catalog.pg_trigger pt, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace AND pc.oid=pt.tgrelid
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pt.tgisinternal=false
) LOOP
EXECUTE format('DROP TRIGGER %I ON %I.%I;',
r.tgname, r.nspname, r.relname);
END LOOP;
-- constraints #1: foreign key
FOR r IN (SELECT pns.nspname, pc.relname, pcon.conname
FROM pg_catalog.pg_constraint pcon, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace AND pc.oid=pcon.conrelid
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pcon.contype='f'
) LOOP
EXECUTE format('ALTER TABLE ONLY %I.%I DROP CONSTRAINT %I;',
r.nspname, r.relname, r.conname);
END LOOP;
-- constraints #2: the rest
FOR r IN (SELECT pns.nspname, pc.relname, pcon.conname
FROM pg_catalog.pg_constraint pcon, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace AND pc.oid=pcon.conrelid
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pcon.contype<>'f'
) LOOP
EXECUTE format('ALTER TABLE ONLY %I.%I DROP CONSTRAINT %I;',
r.nspname, r.relname, r.conname);
END LOOP;
-- indicēs
FOR r IN (SELECT pns.nspname, pc.relname
FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pc.relkind='i'
) LOOP
EXECUTE format('DROP INDEX %I.%I;',
r.nspname, r.relname);
END LOOP;
-- normal and materialised views
FOR r IN (SELECT pns.nspname, pc.relname
FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pc.relkind IN ('v', 'm')
) LOOP
EXECUTE format('DROP VIEW %I.%I;',
r.nspname, r.relname);
END LOOP;
-- tables
FOR r IN (SELECT pns.nspname, pc.relname
FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pc.relkind='r'
) LOOP
EXECUTE format('DROP TABLE %I.%I;',
r.nspname, r.relname);
END LOOP;
-- sequences
FOR r IN (SELECT pns.nspname, pc.relname
FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pc.relkind='S'
) LOOP
EXECUTE format('DROP SEQUENCE %I.%I;',
r.nspname, r.relname);
END LOOP;
-- extensions (only if necessary; keep them normally)
FOR r IN (SELECT pns.nspname, pe.extname
FROM pg_catalog.pg_extension pe, pg_catalog.pg_namespace pns
WHERE pns.oid=pe.extnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
) LOOP
EXECUTE format('DROP EXTENSION %I;', r.extname);
END LOOP;
-- aggregate functions first (because they depend on other functions)
FOR r IN (SELECT pns.nspname, pp.proname, pp.oid
FROM pg_catalog.pg_proc pp, pg_catalog.pg_namespace pns, pg_catalog.pg_aggregate pagg
WHERE pns.oid=pp.pronamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pagg.aggfnoid=pp.oid
) LOOP
EXECUTE format('DROP AGGREGATE %I.%I(%s);',
r.nspname, r.proname,
pg_get_function_identity_arguments(r.oid));
END LOOP;
-- routines (functions, aggregate functions, procedures, window functions)
IF EXISTS (SELECT * FROM pg_catalog.pg_attribute
WHERE attrelid='pg_catalog.pg_proc'::regclass
AND attname='prokind' -- PostgreSQL 11+
) THEN
q := 'CASE pp.prokind
WHEN ''p'' THEN ''PROCEDURE''
WHEN ''a'' THEN ''AGGREGATE''
ELSE ''FUNCTION''
END';
ELSIF EXISTS (SELECT * FROM pg_catalog.pg_attribute
WHERE attrelid='pg_catalog.pg_proc'::regclass
AND attname='proisagg' -- PostgreSQL ≤10
) THEN
q := 'CASE pp.proisagg
WHEN true THEN ''AGGREGATE''
ELSE ''FUNCTION''
END';
ELSE
q := '''FUNCTION''';
END IF;
FOR r IN EXECUTE 'SELECT pns.nspname, pp.proname, pp.oid, ' || q || ' AS pt
FROM pg_catalog.pg_proc pp, pg_catalog.pg_namespace pns
WHERE pns.oid=pp.pronamespace
AND pns.nspname NOT IN (''information_schema'', ''pg_catalog'', ''pg_toast'')
' LOOP
EXECUTE format('DROP %s %I.%I(%s);', r.pt,
r.nspname, r.proname,
pg_get_function_identity_arguments(r.oid));
END LOOP;
-- nōn-default schemata we own; assume to be run by a not-superuser
FOR r IN (SELECT pns.nspname
FROM pg_catalog.pg_namespace pns, pg_catalog.pg_roles pr
WHERE pr.oid=pns.nspowner
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast', 'public')
AND pr.rolname=current_user
) LOOP
EXECUTE format('DROP SCHEMA %I;', r.nspname);
END LOOP;
-- voilà
RAISE NOTICE 'Database cleared!';
END; $$;

在此之后，您可以运行 django 命令进行迁移

python manage.py makemigrations
python manage.py migrate

当然可以，谢谢。

从已安装的应用程序和注释路径(‘ admin/’，admin.site.urls)中注释 django.Contrib.admin，然后重新运行 make 迁移，然后迁移。这能解决你的问题。更多信息请访问 给你

只需 全部删除的 migrations文件夹，__pycache__，.pyc文件:

find . | grep -E "(__pycache__|\.pyc|\.pyo$|migrations)" | xargs rm -rf

然后，跑:

python manage.py makemigrations
python manage.py migrate

当您对默认用户模型进行一些更改时，或者通过抽象用户创建自定义用户模型时，很多时候您将面临这个错误

1: 请记住，当我们创建一个超级用户，然后登录我们需要用户名和密码，但如果你转换 USERNAME _ FIELD =’em ail’，那么现在你不能用用户名和密码登录，因为你的用户名字段转换成电子邮件..。

如果你尝试创建另一个超级用户，那么它不会要求用户名，它只会要求电子邮件和密码，然后创建超级用户的电子邮件和密码后，只有当你尝试登录管理面板，然后它会抛出这个错误，因为没有任何用户名和用户名字段是必需的

2: 这就是为什么在迁移过程中创建自定义用户模型之后，它会抛出这样的错误 解析它 < strong > 首先在 setings.py 中添加 AUTH _ USER _ MODEL = ‘ appname.custommodel name’(appname 是定义定制用户模型的应用程序名称，而定制模型名称是定制用户模型的模型名称) 3: 然后删除创建定制用户模型的应用程序的迁移文件夹，然后删除项目的数据库 db.sqlite3 4: 现在运行侯赛因管理员 python management. py makhemations appname (定义自定义用户模型的应用程序名) 然后通过 python management 进行迁移 就是这样，现在完成了

在我的例子中，问题出在 pytest 启动时，我只是将 --reuse-db修改为 --create-db，运行 pytest 并将其修改回来。这解决了我的问题

这些步骤也可以起作用

1. 删除整个数据库
2. 重新迁徙

这几个步骤可以为您解决这个问题，而且我认为当您有多个参与者参与 Sam 项目时是最好的。

您可以直接删除 db.sqlite3，然后自动生成迁移新数据库。

rm sqlite3.db


python manage.py makemigrations
python manage.py migrate

如何修复(不删除迁移文件夹或整个数据库)

1. 备份你的数据库
2. 在 INSTALLED _ APPS 中注释你的应用，在 setings.py 中注释 AUTH _ USER _ MODEL = ‘ account. User’
3. python manage.py admin zero
4. 撤消步骤2
5. python manage.py migrate

为什么会出现这个问题？

Django 管理应用程序依赖于 AUTH_USER_MODEL，这是您创建 django 项目时的默认认证模型。

如果在更改 AUTH_USER_MODEL之前迁移项目模型，django 管理员应用程序将迁移作为 django 啊模型依赖项应用。但是，您更改了 依赖性并希望再次迁移模型。因此，问题出现在这里; 管理模型应用在它的依赖项之前，也就是现在的 用户模型。因此，您应该恢复管理模型迁移，然后再试一次。

由于您使用的是自定义 User 模型，因此可以首先注释掉

INSTALLED_APPS = [
...
#'django.contrib.admin',
...
]

在您的安装 _ 应用程序设置。还注释

urlpatterns = [
# path('admin/', admin.site.urls)
....
....
]

在你的网址里

那就快跑

python manage.py migrate.

当做无评论

'django.contrib.admin'

还有

path('admin/', admin.site.urls)

如何在生产环境中解决一个奇怪的不一致迁移历史问题

日志看起来运行良好:

>>> ./manage migrate
====== Migrations =====
Running migrations:
Applying app.0024_xxx... OK
Applying app.0025_yyy... OK

但是后来

>>> ./manage migrate
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration app.0025_yyy is applied before its dependency app.0024_xxx on database 'default'.

怎么解决？ 将 app.0025 _ yyy.py 的依赖关系从 0024_xxx手动更改为 0023_prior_migration_name 然后:

>>> ./manage.py makemigrations --merge
Created new merge migration /app/src/app/migrations/0026_merge_20220809_1021.py
>>> ./manage.py migrate
Running migrations:
Applying app.0024_xxx... OK
Applying app.0026_merge_20220809_1021... OK

这解决了问题，但是如果你不想提交你的更改，你可以通过以下方法恢复所有的内容:

>>> ./manage.py migrate app 0023
Running migrations:
Rendering model states... DONE
Unapplying app.0026_merge_20220809_1021... OK
Unapplying app.0024_xxx... OK
Unapplying app.0025_yyy... OK

恢复0025 _ yyy 的依赖关系更改并删除合并迁移。

>>> ./manage migrate
====== Migrations =====
Running migrations:
Applying app.0024_xxx... OK
Applying app.0025_yyy... OK

在我的例子中，我也使用了一个自定义用户。

1-删除所有迁移和数据库表(如果您有测试数据! ! !)。

2-为自定义用户应用程序运行迁移。

python manage.py makemigrations customAuth
python manage.py migrate customAuth

然后为项目级别运行迁移。

python manage.py makemigrations
python manage.py migrate