django.db.migrations.exceptions.InconsistentMigrationHistory

85

Cuando ejecuto python manage.py migratemi proyecto Django, aparece el siguiente error:

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

Tengo un modelo de usuario como el siguiente:

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

¿Como puedó resolver esté problema?

Hari Krishnan
fuente
4
en primer lugar, elimine todas las tablas de la base de datos, elimine todos los archivos de la carpeta de migraciones excepto init.py y luego ejecute
migrate
¿Cómo borrar todas las tablas?
Hari Krishnan
¿Qué base de datos estás usando?
Exprator
yah. Lo he eliminado y ahora está funcionando.
Hari Krishnan
Para mí el problema era porque tenía una migración de la que dependía 'ipn', '__latest__'. Acabo de comprobar el orden o migraciones aplicados con select * from django_migrations, luego cambió __latest__por 'ipn', '0007_auto_20160219_1135'y el problema se ha ido.
Ruben Alves

Respuestas:

46

Su tabla django_migrations en su base de datos es la causa de la inconsistencia y eliminar todas las migraciones solo desde la ruta local no funcionará.

Tienes que truncar la tabla django_migrations de tu base de datos y luego intentar aplicar las migraciones nuevamente. Debería funcionar, pero si no lo hace, vuelva a ejecutar makemigrations y luego migre.

Nota: no olvide realizar una copia de seguridad de sus datos.

Arpit Solanki
fuente
5
No funcionó. Cuando intenté migrar, se quejó de que ya existe una relación. Tenga en cuenta que puede truncar la tabla django_migrations con este comando:> python manage.py shell `` `from django.db import connection cursor = connection.cursor () cursor.execute (" TRUNCATE TABLE django_migrations ")` `` Y puede ver la tabla de migración como esta: `` `de django.db.migrations.recorder import MigrationRecorder MigrationRecorder.Migration.objects.all ()` ``
Almenon
2
Esta es una idea terrible con una alta probabilidad de pérdida de datos. Vea mi respuesta a continuación.
tbm
107

Dado que está utilizando un modelo de usuario personalizado, primero puede comentar

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

en la configuración de Installed_Apps. Entonces corre

python manage.py migrate.

Cuando termine, descomente

'django.contrib.admin'
Jackson
fuente
¡Sí, esto resolvió mi problema! Se cambió el modelo de usuario predeterminado al modelo de usuario abstracto y, después de todas las migraciones, se produjo un error. Pero cuando probé esto, ¡resolví mi problema!
mevaka
29
No me funciona. El mensaje de error es "No hay aplicación de instalación con etiqueta de administrador", ¿primero debo eliminar todos los archivos en las migraciones? alguien sabe como solucionarlo? Gracias ~
Deft-pawN
2
Compruebe a continuación la respuesta del usuario9414732.
Rexcirus
16
no olvide la ruta del comentario ('admin /', admin.site.urls) en urls.py
Vladimir
72

Comencemos abordando el problema con la mayoría de las respuestas en esta página:

Nunca tiene que eliminar su base de datos si está utilizando el sistema de migración de Django correctamente y nunca debe eliminar las migraciones una vez que se hayan confirmado.

Ahora, la mejor solución para usted depende de una serie de factores que incluyen la experiencia que tenga con Django, el nivel de comprensión que tenga del sistema de migración y el valor de los datos en su base de datos.

En resumen, hay dos formas de abordar cualquier error de migración.

  1. Toma la nuclear opción . Advertencia: esta es solo una opción si está trabajando solo. Si otras personas dependen de las migraciones existentes, no puede simplemente eliminarlas.

    • Elimine todas sus migraciones y reconstruya un conjunto nuevo con python3 -m manage makemigrations . Esto debería eliminar cualquier problema que haya tenido con las dependencias o inconsistencias en sus migraciones.
    • Elimina toda tu base de datos. Esto eliminará cualquier problema que haya tenido con inconsistencias entre su esquema de base de datos real y el esquema que debería tener basado en su historial de migración, y eliminará cualquier problema que haya tenido con inconsistencias entre su historial de migración y sus archivos de migración anteriores [esto es lo que se InconsistentMigrationHistoryestá quejando].
    • Recrea tu esquema de base de datos con python3 -m manage migrate
  2. Determine la causa del error y resuélvala, porque (hablando por experiencia) la causa es casi con certeza algo tonto que usted hizo. (Generalmente como resultado de no entender cómo usar correctamente el sistema de migración). Según los errores que he causado, hay tres categorías.

    1. Inconsistencias con los archivos de migración. Esto es bastante común cuando varias personas están trabajando en un proyecto. Con suerte, sus cambios no entran en conflicto ymakemigrations --merge puedan resolver este; de ​​lo contrario, alguien tendrá que revertir sus migraciones al punto de ramificación para resolver esto.
    2. Inconsistencias entre su esquema y su historial de migración. Para administrar esto, alguien habrá editado el esquema de la base de datos manualmente o eliminado las migraciones. Si eliminaron una migración, revertir sus cambios y gritarles; nunca deberías eliminar las migraciones si otras personas dependen de ellas. Si editaron el esquema de la base de datos manualmente, revierta sus cambios y luego gríteles; Django está administrando el esquema de la base de datos, nadie más.
    3. Inconsistencias entre su historial de migración y sus archivos de migraciones. [Este es el InconsistentMigrationHistoryproblema que sufre el autor de la pregunta y el que yo sufría cuando llegué a esta página]. Para administrar esto, alguien ha manipulado manualmente la django_migrationstabla o ha eliminado una migración después de que se aplicó. Para resolver esto, tendrá que averiguar cómo se produjo la inconsistencia y resolverla manualmente. Si el esquema de su base de datos es correcto, y solo su historial de migración es incorrecto, puede editar manualmente la django_migrationstabla para resolver esto. Si el esquema de su base de datos es incorrecto, también tendrá que editarlo manualmente para alinearlo con lo que debería ser.

Según su descripción del problema y la respuesta que seleccionó, asumiré que está trabajando solo, es nuevo en Django y no se preocupa por sus datos. Entonces, la opción nuclear puede ser adecuada para usted.

Si no se encuentra en esta situación y el texto anterior parece un galimatías, le sugiero que pida ayuda a la Lista de correo del usuario de Django . Hay personas muy útiles que pueden ayudarlo a resolver el problema específico en el que se encuentra.

¡Ten fe, puedes resolver este error sin volverte nuclear!

Aires
fuente
1
Para aquellos interesados: en mi caso, había creado una migración temporal para crear tablas en la aplicación B mientras esperaba que mi compañero de trabajo terminara las migraciones personalizadas para mover las tablas de la aplicación A a la aplicación B. Cuando mi compañero de trabajo terminó, revirtí mi migración temporal y se fue a aplicar migraciones. Error de Bam. No solo me olvidé de anular la aplicación de mi migración temporal, sino que logré nombrar la migración temporal de la misma manera que la actual. ¡Al sistema de migración, la migración de la aplicación B, 0001_initialque dependía de la 00XX_automigración de la aplicación A, se había aplicado de alguna manera antes de su dependencia!
emite el
2
Por horrible que parezca, fue fácil de resolver. Mi base de datos tenía el esquema correcto, por lo que todo lo que tenía que hacer era agregar manualmente 'A' '00XX_auto'a la django_migrationstabla para que mi historial reflejara que se habían aplicado los cambios en esa migración. Complicado, pero no tan difícil una vez que resuelve el problema.
Aires
Puede migraciones no sólo de borrado, es necesario eliminar la pycache demasiado
JonPizza
Me metí en este lío porque tenía un montón de tablas de datos iniciales que no eran de Django, por lo que la mayoría de mis modelos las tenían managed = False. Cuando decidí dejar que ORM hiciera su trabajo y pasar a modelos administrados (como una forma de hacer que mis pruebas se ejecutaran), entonces comenzó toda mi "diversión".
cjm
Debe eliminar absolutamente las migraciones si su equipo decide aplastar desde 0001 hasta 0230 o sin embargo, cientos de migraciones tiene: confirma la migración aplastada, espera a que CI / CD la aplique y, una vez que prod se haya puesto al día por completo , elimine los archivos originales 0001 _... a 0230 _... porque ya no hacen nada, y usted actualiza las migraciones de squash para que ya no diga replacesnada. Mantener las viejas migraciones solo hará que la vida del desarrollador sea un infierno para su equipo cuando alguien necesite averiguar cuál de las incontables 0002 migraciones es la real.
Mike 'Pomax' Kamermans
37

Aquí cómo resolver esto correctamente.

Siga estos pasos en su carpeta de migraciones dentro del proyecto:

  1. Elimine los archivos _pycache_ y 0001_initial.
  2. Elimine db.sqlite3 del directorio raíz (tenga cuidado de que todos sus datos desaparezcan).
  3. en la terminal ejecutar:
      python manage.py makemigrations
      python manage.py migrar

Voila.

Dr. Younes Henni
fuente
1
¿Qué pasa si no queremos eliminar y en modo producción? Además, no estoy usando sqllite, es MySQL en nuestro servidor. ¿Cuál es el mejor método sin perder datos?
Bishwas Bhandari
33

Esto me sucedió en un nuevo proyecto después de agregar un modelo de usuario personalizado, según la recomendación en los documentos de django.

Si está iniciando un nuevo proyecto, se recomienda encarecidamente configurar un modelo de usuario personalizado, incluso si el modelo de usuario predeterminado es suficiente para usted.

Esto es lo que hice para resolver el problema.

  1. Elimine la base de datos db.sqlite3.
  2. Elimina la carpeta de aplicaciones / migraciones.

Por @jackson, comenta temporalmente django.contrib.admin.

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

También comente el sitio de administración en urls.py:

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

Si no comenta la ruta ('admin /'), obtendrá el error "LookupError: No hay aplicación instalada con la etiqueta 'admin'" cuando ejecute

python manage.py migrate

Una vez finalizadas las migraciones, elimine los comentarios de los dos anteriores.

usuario9414732
fuente
26

Problema

django.db.migrations.exceptions.InconsistentMigrationHistory: La migración admin.0001_initial se aplica antes de su cuenta de dependencia.0001_initial en la base de datos 'predeterminada'.

Entonces podemos migrar la base de datos sin administrador (admin.0001_initial) en primer lugar.

Después de migrar su dependencia, ejecute los comandos para migrar admin.0001_initial.

Solución

  1. elimine 'django.contrib.admin' de INSTALLED_APPS en settings.py.
  2. ejecutar comandos:

Python manage.py makemigrations nombre de la aplicación

Python manage.py migrar nombre de aplicación

  1. agregue 'django.contrib.admin' a INSTALLED_APPS en el archivo settings.py.
  2. ejecutar comandos de nuevo:

Python manage.py makemigrations nombre de la aplicación

Python manage.py migrar nombre de aplicación

kun shi
fuente
7
Para mí, eliminar 'django.contrib.admin' de INSTALLED_APPS y ejecutar makemigrations da como resultadoLookupError: No installed app with label 'admin'.
Szymon Przedwojski
4
vaya a urls.py y comente las URL con el administrador
Gautam Kumar
2

simplemente elimine el archivo sqlite o ejecute flush the databse 'python manage.py flush' y luego ejecute los comandos makemigrations y migrate respectivamente.

Arun
fuente
2

cuando crea un nuevo proyecto de Django y ejecuta

python manage.py migrar

Django creará 10 tablas para usted de forma predeterminada, incluida una tabla auth_user y dos comienzan con auth_user.

cuando desee crear un modelo de usuario personalizado heredado de AbstractUser, encontrará este problema con el siguiente mensaje de error:

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

Resuelvo este problema eliminando toda mi base de datos y creo una nueva. Y esto reemplazó las tres tablas que mencioné.

hcf1425
fuente
2
Bien, ¿y si no quisiera eliminar mi base de datos? ¿Existe alguna solución disponible?
Iulian Pinzaru
2

Antes de realizar cualquier otro paso, haga una copia de seguridad de su base de datos. Luego retrocede de nuevo.

Elimine cualquier código de modelo de usuario personalizado, desactive su modelo y aplicación personalizados en la configuración, luego:

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

Luego agregue su modelo personalizado, configúrelo en la configuración y vuelva a habilitar la aplicación. Asegúrese de no tener migraciones en esta aplicación todavía.

Luego:

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.

¡Hecho!

tbm
fuente
2

Resuelto comentando esto antes de la migración en settings.py 'django.contrib.admin' y en urls.py, ('admin/', admin.site.urls). descomentar después de migrar

NaSir HuSSaiN
fuente
publicar código (reemplazo) en forma de script y en la parte superior donde comienza el código, cada bloque comienza con un nombre de archivo que representa un script. La forma en que publicaste tu respuesta me confunde.
ZF007
@ ZF007 Perdón por la confusión. Soy un poco nuevo en StackOverflow, así que no entendí cómo publicar una respuesta
NaSir HuSSaiN
1

Primero elimine todas las migraciones y los archivos db.sqlite3 y siga estos pasos:

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

Elimina el antiguo archivo de migración y finalmente.

$ ./manage.py migrate
shivam singhal
fuente
1

Tu error es esencialmente:

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

Verificación de cordura : Primero, abra su base de datos y observe los registros en la tabla 'django_migrations'. Los registros deben enumerarse en orden cronológico (por ejemplo: A, B, C, D ...).

Asegúrese de que el nombre de la migración "A" que aparece en el error coincida con el nombre de la migración "A" que aparece en la base de datos. (Pueden diferir si anteriormente, manualmente, editó, eliminó o renombró archivos de migración)

Para solucionar este problema , cambie el nombre de la migración A. en la base de datos o cambie el nombre del archivo. PERO asegúrese de que los cambios coincidan con lo que otros desarrolladores de su equipo tienen en sus bases de datos (o que los cambios coincidan con los de su base de datos de producción)

Michael Romrell
fuente
1

Si está trabajando en una base de datos vacía, una solución rápida podría ser ejecutar las migraciones para la aplicación de la cuenta , antes que cualquier otra migración de la aplicación.

$ ./manage.py migrate account

Y entonces:

$ ./manage.py migrate
Duilio
fuente
1

El orden de INSTALLED_APPSparece importante. Si siempre coloca sus trabajos recientes en la parte superior o al principio de la lista, siempre se cargarán correctamente con respecto a django.contrib.admin. Mover mis trabajos al principio de la INSTALLED_APPSlista me solucionó este problema. La razón por la que la solución de Kun Shi pudo haber funcionado tal vez fue porque ejecutó las migraciones en un orden diferente.

altdelete
fuente
0

Si esa excepción se reveló por sí misma mientras intenta crear su propio modelo de usuario en lugar de seguir las instrucciones estándar
, he encontrado que mi problema se resuelve siguiendo esas instrucciones paso a paso:

  1. Cree un modelo de usuario personalizado idéntico a auth.User, llámelo Usuario (las tablas de muchos a muchos mantienen el mismo nombre) y establezca db_table = 'auth_user' (para que use la misma tabla)
  2. Tira todas tus migraciones
  3. Recrea un nuevo conjunto de migraciones
  4. Sacrifica un pollo, quizás dos si estás ansioso; también haga una copia de seguridad de su base de datos
  5. Truncar la tabla django_migrations
  6. Aplicar falsamente el nuevo conjunto de migraciones
  7. Desmarque db_table, realice otros cambios en el modelo personalizado, genere migraciones, aplíquelas

Se recomienda encarecidamente hacer esto en una base de datos que aplique restricciones de clave externa. ¡No intente esto en SQLite en su computadora portátil y espere que funcione en Postgres en los servidores!

ncopiy
fuente
¿Podría agregar un resumen o una cita del artículo vinculado a su respuesta?
Collin M. Barrett
0

Si configura AUTH_USER_MODE L en settings.py así:

AUTH_USER_MODEL = 'custom_user_app_name.User'

usted debe comentar esta línea antes de correr makemigration y Migración de comandos. Luego, puede descomentar esta línea nuevamente.

Erfan Tahriri
fuente
3
Desafortunadamente, esto me genera errores, por ejemplo:accounts.CustomUser.groups: (fields.E304) Reverse accessor for 'CustomUser.groups' clashes with reverse accessor for 'User.groups'. HINT: Add or change a related_name argument to the definition for 'CustomUser.groups' or 'User.groups'.
Szymon Przedwojski
0

cuando crea un nuevo proyecto y sin aplicaciones, ejecuta el

python manage.py migrate

Django creará 10 tablas por defecto.

Si desea crear un modelo de usuario de cliente que herede AbstractUserdespués de eso, encontrará este problema como el siguiente mensaje:

django.db.migrations.exceptions.InconsistentMigrationHistory: La migración admin.0001_initial se aplica antes de su cuenta de dependencia.0001_initial en la base de datos 'predeterminada'.

finalmente, dejo caer todas mis bases de datos y ejecuto

hcf1425
fuente
0

Encontré esto al migrar de Wagtail 2.0 a 2.4, pero lo he visto algunas otras veces cuando una aplicación de terceros aplasta una migración después de su versión actual pero antes de la versión a la que está migrando.

La solución sorprendentemente simple en este caso al menos es:

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

es decir, ejecute una única migración antes de intentar realizar migraciones.

Rick Westera
fuente
0

Hay otra razón además del error del usuario que puede conducir a este tipo de problema: un problema conocido con Django cuando se trata de migraciones aplastadas.

Tenemos una serie de migraciones que funcionan perfectamente bien en Python 2.7 + Django 1.11. Ejecutando makemigrationso migratesiempre funciona como debería, etc., incluso (con el propósito de probar) cuando la base de datos se ha recreado recientemente.

Sin embargo, cuando movemos un proyecto a Python 3.6 (actualmente usando el mismo Django 1.11), me he quedado atascado tratando de averiguar por qué las mismas migraciones se aplican bien solo la primera vez que se ejecutan. Después de eso, cualquier intento de ejecución makemigrationso incluso simplemente migrateda como resultado el error:

django.db.migrations.exceptions.InconsistentMigrationHistory

en el que la migración foo.0040-thingse aplica antes de su dependencia foo.0038-something-squashed-0039-somethingelse(solo tenemos esa migración aplastada ... el resto es mucho más sencillo).

Lo que me molestó por un tiempo es por qué esto solo sucede en Python 3. Si la base de datos es realmente inconsistente, esto debería estar sucediendo todo el tiempo. Que las migraciones parezcan funcionar perfectamente bien la primera vez que se aplican fue igualmente confuso.

Después de mucha búsqueda (incluido el actual hilo de preguntas y respuestas), me topé con el informe de error de Django mencionado anteriormente . Nuestra migración de squash de hecho usó el bprefijo en la replaceslínea (por ejemplo,replaces = [(b'', 'foo.0038-defunct'),.......]

Una vez que eliminé los bprefijos de la replaceslínea, todo funcionó normalmente.

MartyMacGyver
fuente
0

Este problema surgirá la mayor parte del tiempo si extiende el modelo de usuario después de la migración inicial. Porque siempre que amplíe el usuario abstracto, creará campos básicos que estaban presentes en el modelo como correo electrónico, nombre, etc.

Incluso esto es aplicable a cualquier modelo abstracto en django.

Entonces, una solución muy simple para esto es crear una nueva base de datos y luego aplicar las migraciones o eliminar [todos los datos se eliminarán en este caso] la misma base de datos y volver a aplicar las migraciones.

Mayank Pratap Singh
fuente
0

en primer lugar, haga una copia de seguridad de sus datos. (copie su archivo db).

elimine sqlite.db y también la carpeta de migración .

luego, ejecute estos comandos:

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

después de eliminar el archivo DB y la carpeta de migración, asegúrese de escribir el nombre de la aplicación después de los comandos de migración.

imansdn
fuente
0

Bien, antes de hacer algo extraño o nuclear, primero suelte su base de datos y reconstruya.

Si usa POsgres -

DROP SCHEMA public CASCADE;
CREATE SCHEMA PUBLIC;

Entonces simplemente rehaga sus migraciones

./manage.py migrate

Esta es la solución más básica, que normalmente aclarará las cosas. No se limite a rehacer las migraciones hasta que sea absolutamente necesario.

JoCee
fuente
4
"cualquier cosa extraña o nuclear" y luego "primero suelta tu base de datos y reconstruyela". Si eliminar la base de datos no se considera nuclear, odiaría ver qué es.
tbm
0

Tengo que soltar mi base de datos y luego ejecutar makemigrations y migrar nuevamente para que esto se resuelva por mi parte.

Flavinas
fuente
0

elimine la carpeta de migraciones y db.sqlite3 y escriba el cmd python manage.py makemigrations

moncef banouri
fuente
1
Si bien esto puede solucionar el problema, ¿podría proporcionar información sobre por qué también lo solucionará?
bob0the0mighty
porque ya creó una base de datos SQL con una estructura y algunos datos en ella y cuando realiza algunos cambios que podrían tocar sus datos y modificar su modelo, se ejecuta un error
Moncef Banouri
0

django.db.migrations.exceptions.InconsistentMigrationHistory # al crear un modelo de usuario personalizado

Tuve el mismo problema hoy, y ninguna de las soluciones anteriores funcionó, luego pensé en borrar todos los datos de mi base de datos local de PostgreSQL usando este siguiente comando

-- 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; $$;

Después de esto, puede ejecutar el comando django para migraciones

python manage.py makemigrations
python manage.py migrate

Y absolutamente eso funcionará. Gracias.

Faisal Nazik
fuente
0

Comente django.contrib.admin desde las aplicaciones instaladas y también la ruta del comentario ('admin /', admin.site.urls), luego vuelva a ejecutar makemigrations y luego migre. Resolverá tu problema. Para más información vaya aquí

Subham Singh
fuente
1
Algunos consejos: trate de no duplicar respuestas que ya existen. Parece que ya hay una solución seleccionada. Si su respuesta es diferente, explique por qué y proporcione más detalles si puede. Por ejemplo, ¿cuál es la lógica para comentar sobre django.contrib.admin (también, te refieres a comentar?). ¿Por qué volver a ejecutar la migración?
Jairus Martin