django.db.migrations.exceptions.InconsistentMigrationHistory

当我python manage.py migrate在Django项目上运行时，出现以下错误：

Traceback (most recent call last):
File "manage.py", line 22, in <module>
execute_from_command_line(sys.argv)
File "/home/hari/project/env/local/lib/python2.7/site-     packages/django/core/management/__init__.py", line 363, in execute_from_command_line
utility.execute()
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 355, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 283, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 330, in execute
output = self.handle(*args, **options)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 86, in handle
executor.loader.check_consistent_history(connection)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/db/migrations/loader.py", line 298, in check_consistent_history
connection.alias,
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'.

我有一个如下的用户模型：

class User(AbstractUser):
    place = models.CharField(max_length=64, null=True, blank=True)
    address = models.CharField(max_length=128, null=True, blank=True)

我怎么解决这个问题？

数据库中的django_migrations表是导致不一致的原因，仅从本地路径删除所有迁移将不起作用。

您必须从数据库中截断django_migrations表，然后尝试再次应用迁移。它应该可以工作，但是如果不起作用，则再次运行makemigrations，然后进行迁移。

注意：不要忘记备份数据。

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

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

在您的Installed_Apps设置中。然后跑

python manage.py migrate.

取消注释后

'django.contrib.admin'

让我们首先使用本页上的大多数答案解决问题：

你永远不会有，如果你正确使用Django的迁移系统放弃你的数据库，你应该永远不会删除迁移一旦被comitted

现在，最适合您的解决方案取决于许多因素，其中包括您对Django的经验，对迁移系统的了解水平以及数据库中数据的价值。

简而言之，有两种方法可以解决任何迁移错误。

1. 采取核选择。警告：仅当您独自工作时，这是一个选择。如果其他人依赖现有迁移，则不能删除它们。

   • 删除所有迁移，然后使用 python3 -m manage makemigrations。这应该消除您在迁移过程中遇到的依赖关系或不一致问题。
   • 删除整个数据库。这将消除您在实际数据库架构与应基于迁移历史记录的架构之间存在的不一致问题，并消除在迁移历史记录与先前的迁移文件之间存在的不一致问题[这就是问题该InconsistentMigrationHistory在抱怨]。
   • 重新创建您的数据库架构 python3 -m manage migrate

2. 确定错误原因并加以解决，因为（从经验上讲）原因几乎可以肯定是您所做的某件事。（通常是由于不了解如何正确使用迁移系统）。基于错误的原因，我将其分为三类。

   1. 与迁移文件不一致。当多个人在一个项目上工作时，这是一种很常见的做法。希望您的更改不会冲突并且makemigrations --merge可以解决此问题，否则某人将必须将其迁移回滚到分支点才能解决此问题。
   2. 模式与迁移历史记录之间的不一致。为了管理此问题，将需要手动编辑数据库架构或删除迁移。如果他们删除了迁移，则恢复所做的更改并大喊大叫；你永远不应该删除迁移，如果别人依赖他们。如果他们手动编辑数据库模式，请还原他们的更改，然后大喊大叫；Django正在管理数据库架构，没有其他人可以管理。
   3. 迁移历史记录和迁移文件之间的不一致。[这是InconsistentMigrationHistory问问者所遭受的问题，也是我到达此页面时所遭受的问题]。为了进行管理，有人手动将django_migrations表弄乱了，或者在应用迁移后删除了迁移。要解决此问题，您将必须弄清不一致的产生原因并手动解决。如果您的数据库架构是正确的，并且只是您的迁移历史记录是错误的，则可以手动编辑django_migrations表以解决此问题。如果您的数据库模式错误，那么您还必须手动对其进行编辑，以使其与实际情况保持一致。

根据对问题的描述和选择的答案，我将假设您是一个人工作，是Django的新手，并且不在乎您的数据。因此，核选项可能适合您。

如果您不在这种情况下，并且上面的文本看起来像胡言乱语，那么我建议向Django用户的邮件列表寻求帮助。那里有很多乐于助人的人，可以帮助您解决您所处的特定困境。

有信心，您可以解决此错误而无需核！

这里如何正确解决这个问题。

在项目内的迁移文件夹中执行以下步骤：

1. 删除_pycache_和0001_initial文件。
2. 从根目录中删除db.sqlite3（请注意，所有数据都会消失）。
3. 在终端上运行：
   python manage.py makemigrations
   python manage.py migration

瞧

根据django文档中的建议，在添加自定义用户模型后，这在新项目中发生了。

如果您要开始一个新项目，强烈建议您设置一个自定义用户模型，即使默认用户模型足以满足您的需要。

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

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

根据@jackson，暂时将django.contrib.admin注释掉。

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

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

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

如果不注释路径（'admin /'），则在运行时会出现错误“ LookupError：未安装带有标签'admin'的应用”

python manage.py migrate

迁移完成后，请取消注释以上两项。

问题

django.db.migrations.exceptions.InconsistentMigrationHistory：迁移admin.0001_initial在数据库'default'的依赖项account.0001_initial之前应用。

因此，我们可以首先在没有admin（admin.0001_initial）的情况下迁移数据库。

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

解

1. 从settings.py中的INSTALLED_APPS中删除“ django.contrib.admin”。
2. 执行命令：

Python manage.py makemigrations应用程序名称

Python manage.py迁移应用名称

3. 在settings.py文件中的INSTALLED_APPS中添加“ django.contrib.admin”。
4. 再次执行命令：

Python manage.py makemigrations应用程序名称

Python manage.py迁移应用名称

只需删除sqlite文件或运行刷新数据库“ python manage.py flush”，然后分别运行makemigrations和migration命令。

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

python manage.py迁移

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'.

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

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

移除所有自定义用户模型代码，禁用设置中的自定义模型和应用，然后：

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.

做完了！

通过在迁移之前在settings.py'django.contrib.admin' 和urls.py，中 注释此问题来解决 ('admin/', admin.site.urls)。迁移后取消注释

首先删除所有迁移文件和db.sqlite3文件，然后执行以下步骤：

$ ./manage.py makemigrations myapp 
$ ./manage.py squashmigrations myapp 0001(may be differ)

最后删除旧的迁移文件。

$ ./manage.py migrate

您的错误本质上是：

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

完整性检查：首先，打开数据库，然后查看“ django_migrations”表中的记录。记录应按时间顺序列出（例如：A，B，C，D ...）。

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

要解决此问题，请在数据库中重命名迁移A.或重命名文件名。但是请确保更改与您团队中其他开发人员在其数据库中拥有的匹配（或更改与您的生产数据库中的匹配）

如果您使用的是空数据库，则可以在进行任何其他应用程序迁移之前快速解决该帐户应用程序的迁移问题。

$ ./manage.py migrate account

然后：

$ ./manage.py migrate

如果在尝试创建自己的用户模型（而不是标准模型）时发现了这种异常，请按照该说明进行操作，
我发现我的问题已解决，请按照以下说明进行操作：

1. 创建一个与auth.User相同的自定义用户模型，将其命名为User（许多表保持相同的名称）并设置db_table ='auth_user'（因此它使用相同的表）
2. 放弃所有迁移
3. 重新创建一组新的迁移
4. 牺牲一只鸡，如果您着急的话，也许两只。还备份您的数据库
5. 截断django_migrations表
6. 假套用新的迁移集
7. 取消设置db_table，对自定义模型进行其他更改，生成迁移，然后应用它们

强烈建议在强制执行外键约束的数据库上执行此操作。不要在笔记本电脑上的SQLite上尝试此操作，并期望它可以在服务器上的Postgres上运行！

如果您在settings.py中设置AUTH_USER_MODE L像这样：

AUTH_USER_MODEL = 'custom_user_app_name.User'

你应该评论运行前该行makemigration和迁移命令。然后，您可以再次取消注释此行。

当您创建一个新项目且没有任何应用程序时，您将运行

python manage.py migrate

Django默认会创建10个表。

如果要创建从其继承的客户用户模型AbstractUser，则将遇到此问题，如下所示：

django.db.migrations.exceptions.InconsistentMigrationHistory：在数据库'default'上的admin.0001_initial依赖项之前应用迁移admin.0001_initial。

最后，我删除了整个数据库并运行

从Wagtail 2.0迁移到2.4时，我遇到了此问题，但在第三方应用程序在当前版本之后但要迁移到的版本之前，对迁移进行了其他几次压缩。

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

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

即在尝试进行迁移之前运行一次迁移。

除了用户错误之外，还有另一个原因可能导致这种问题：Django在压缩迁移方面的一个已知问题。

我们进行了一系列迁移，这些迁移在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上发生。如果DB确实不一致，那么这种情况应该一直发生。同样地，迁移在第一次应用时似乎运行良好。

经过大量搜索（包括当前的问答环节），我偶然发现了上述Django错误报告。我们的南瓜迁移确实确实在行中使用了b前缀replaces（例如，replaces = [(b'', 'foo.0038-defunct'),.......]

一旦我b从replaces行中删除了前缀，它们都可以正常工作。

如果您在初始迁移后扩展用户模型，则大多数情况下会出现此问题。因为每当扩展Abstract用户时，它将创建模型中显示的基本字段，例如email，first_name等。

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

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

首先备份您的数据。（复制您的数据库文件）。

删除sqlite.db以及迁移文件夹。

然后，运行以下命令：

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

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

好的，在您进行任何奇怪或有核的操作之前，请先删除数据库并重建它。

如果使用POsgres-

DROP SCHEMA public CASCADE;
CREATE SCHEMA PUBLIC;

然后重新进行迁移

./manage.py migrate

这是最基本的解决方案，通常可以解决问题。除非绝对必要，否则不要重新构建迁移。

我必须将数据库放到，然后运行makemigrations并再次迁移，以便由我自己解决。

删除迁移文件夹和db.sqlite3并输入cmd python manage.py makemigrations

的顺序INSTALLED_APPS似乎很重要。如果您始终将您的近期作品放在列表的顶部/开头，那么对于django.contrib.admin而言，它们将始终被正确加载。将我的作品移到INSTALLED_APPS列表的开头对我来说解决了这个问题。Kun Shi的解决方案可能起作用的原因也许是按照不同的顺序进行了迁移。

django.db.migrations.exceptions.InconsistentMigrationHistory＃创建自定义用户模型时

今天我遇到了同样的问题，以上解决方案均无效，然后我想使用以下命令从本地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

绝对可以。谢谢。