django.db.les migrations.des exceptions.InconsistentMigrationHistory

Quand je lance

python manage.py migrate

sur mon projet django, j'obtient l'erreur suivante

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

J'ai un modèle utilisateur comme ci-dessous

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

Alors, comment puis-je résoudre ce problème?

tout d'abord supprimer toutes les tables de la base de données, supprimer tous les fichiers de migrations dossier, à l'exception init.py exécutez ensuite migrer
comment supprimer toutes les tables?
ce db utilisez-vous?
yah. je l'ai supprimé et maintenant, il est de travail.
ok poster bro

OriginalL'auteur Hari Krishnan | 2017-06-20

  1. 15

    Votre django_migrations table dans votre base de données est la cause de l'incohérence et la suppression de tous les migrations juste de chemin d'accès local ne fonctionne pas.

    Vous tronquer la django_migrations table de votre base de données et puis essayez d'appliquer les migrations de nouveau. Il devrait fonctionner, mais si il ne le fait pas exécuter makemigrations de nouveau et ensuite migrer.

    Remarque: n'oubliez pas de faire une sauvegarde de vos données.

    N'a pas fonctionné. Quand j'ai essayé de la migration, il s'est plaint qu'une relation existe déjà. Notez que vous pouvez tronquer django_migrations table avec cette commande: > python manage.py shell ` " de django.db importation de connexion curseur = connexion.curseur() curseur.execute("TRUNCATE TABLE django_migrations") ` "Et, vous pouvez consulter le tableau de migration comme ceci: `" de django.db.les migrations.enregistreur d'importation MigrationRecorder MigrationRecorder.La Migration.objets.tous les() ``

    OriginalL'auteur Arpit Solanki

  2. 41

    Puisque vous êtes en utilisant une mesure de modèle d'Utilisateur, votre premier commentaire 

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

    dans votre Installed_Apps paramètres. Ensuite, exécutez

    python manage.py migrate.

    Quand fait décommentez 

    ‘django.contrib.admin’.
    Wow vous êtes un épargnant de vie. Cela m'a sauvé beaucoup de temps. Exactement la réponse nécessaire. Merci!!

    OriginalL'auteur jackson

  3. 20

    Permet de commencer par aborder la question avec la plupart des réponses sur cette page:

    Vous n'avez jamais ont pour déposer votre base de données si vous utilisez Django de migration du système correctement et vous devrait ne jamais supprimer les migrations, une fois qu'ils sont partie prenante

    Maintenant pour vous la meilleure solution dépend d'un certain nombre de facteurs, dont les suivants degré d'expérience avec Django, quel est le niveau de compréhension que vous avez de la migration du système, et la valeur de votre base de données.

    En bref, il y a deux façons de répondre à des migrations d'erreur.

    1. Prendre la nucléaire option. Avertissement: ce n'est qu'une option est que vous travaillez seul. Si d'autres personnes dépendent de l'existant migrations vous ne peut pas simplement les supprimer.

      • Supprimer toutes vos migrations, et de reconstruire un nouveau jeu avec python3 -m manage makemigrations. Ceci devrait permettre d'éliminer tous les problèmes que vous avez eu avec dépendances ou des incohérences dans votre migrations.
      • Déroulant l'ensemble de votre base de données. Cela permettra d'éliminer tous les problèmes que vous avez eu avec des incohérences vous avez eu entre votre schéma de base de données et le schéma, vous devriez avoir basées sur votre historique de migration, et à retirer tous les problèmes que vous avez eu avec les incohérences entre votre histoire de la migration et de vos fichiers de migration [c'est ce que le InconsistentMigrationHistory se plaint].
      • Recréer votre schéma de base de données avec python3 -m manage migrate

    2. Déterminer la cause de l'erreur et de le résoudre, parce que (en parlant de l'expérience) la cause est presque certainement quelque chose de stupide vous fait. (Généralement le résultat de ne pas comprendre comment utiliser le système de migration correctement). En fonction de l'erreur est que j'ai causé il y a trois catégories.

      1. Les incohérences avec les fichiers de migration. C'est une jolie commune lorsque plusieurs personnes travaillent sur un même projet. Espérons que vos modifications ne sont pas en conflit et makemigrations --merge pouvez résoudre ce problème, sinon quelqu'un va avoir à faire reculer leurs migrations vers le point d'embranchement afin de résoudre ce problème.
      2. Incohérences entre votre schéma et votre histoire de la migration. Pour gérer ce quelqu'un soit modifié le schéma de base de données manuellement, ou supprimé des migrations. Si la suppression d'une migration, puis revenir leur évolution et de crier à eux; vous devriez jamais supprimer les migrations si les autres en dépendent. Si ils ont édité le schéma de base de données manuellement, revenir sur leurs modifications et ensuite crier à eux; Django, c'est de gérer le schéma de base de données, et aucun autre.
      3. Incohérences entre votre histoire de la migration et les migrations des fichiers. [C'est le InconsistentMigrationHistory question à la personne souffre de, et celles que j'ai souffert quand je suis arrivé à cette page]. Pour gérer ce que quelqu'un a soit manuellement, gâché avec de l' django_migrations table ou supprimé une migration après il a été appliqué. Pour résoudre cela, vous allez avoir à travailler sur la façon de l'incohérence et résoudre manuellement. Si votre schéma de base de données est correct, et il est juste de votre histoire de la migration qui est mal, vous pouvez modifier manuellement le django_migrations table pour résoudre ce problème. Si votre schéma de base de données est incorrecte, alors vous aurez également à modifier manuellement que pour la mettre en conformité avec ce qu'elle devrait être.

    Basé sur la description du problème et la réponse que vous avez sélectionné, je vais supposer que vous travaillez seul, sont de nouveau à Django, et ne se soucient pas de vos données. Si l'option nucléaire peut être bon pour vous.

    Si vous n'êtes pas dans cette situation et le texte ci-dessus ressemble à du charabia, alors je suggère de poser la Django de l'Utilisateur de la Liste de Diffusion pour obtenir de l'aide. Il y a de très utile, les gens là-bas qui peuvent aider à vous guider à travers la résolution du spécifique de la pagaille que vous êtes dans.

    Avez la foi, vous pouvez résoudre cette erreur sans nucléaire!

    Pour ceux qui sont intéressés: Dans mon cas, j'avais créé une migration temporaire de créer des tables dans l'application B alors que j'étais en attente dans ma collègue pour terminer personnalisé migrations pour déplacer les tables de l'application A app B. Lorsque ma collègue de travail terminée, je revenue de ma migration temporaire et est allé à appliquer les migrations. Bam erreur. Non seulement ai-je oublié d'annuler mon temp de migration, mais avait réussi à le nom de la temp de la migration la même que celle réelle. Le système de migration de l'application B 0001_initial la migration, qui dépendait de l'application de la 00XX_auto la migration avait été en quelque sorte appliqué avant qu'elle dépendance!
    Aussi horrible que tout ce que les sons qu'il était facile à résoudre. Ma base de données n'avez le schéma correct, tout ce que je avais à faire était d'ajouter manuellement 'A' '00XX_auto' à la django_migrations table donc mon histoire reflète les changements dans le fait que la migration avait été appliquée. Compliqué, mais pas difficile une fois que vous travaillez sur le problème.

    OriginalL'auteur Airs

  4. 6

    Ici comment résoudre ce problème correctement.

    Suivez ces étapes dans votre migrations dossier à l'intérieur du projet:

    1. Supprimer la _pycache_ et la 0001_initial fichiers.
    2. Supprimer la db.sqlite3 à partir du répertoire racine (attention toutes vos données vont s'en aller).
    3. sur le terminal, exécutez:
        python manage.py makemigrations

        python manage.py migrer

    Le tour est joué.

    OriginalL'auteur Dr. Younes Henni

  5. 1

    Problème

    django.db.les migrations.des exceptions.InconsistentMigrationHistory: Migration admin.0001_initial est appliquée avant sa dépendance de compte.0001_initial sur la base de données 'par défaut'.

    On peut donc migrer la base de données sans admin(admin.0001_initial) tout d'abord.

    Après sa dépendance migré, exécuter des commandes à migrer admin.0001_initial.

    Solution

    1. supprimer 'django.contrib.admin' de INSTALLED_APPS dans settings.py.
    2. exécuter des commandes:

    Python manage.py makemigrations appname

    Python manage.py migrer appname

    1. ajouter 'django.contrib.admin' pour INSTALLED_APPS dans settings.py fichier.
    2. exécuter des commandes à nouveau:

    $: Python manage.py makemigrations appname

    $: Python manage.py migrer appname

    OriginalL'auteur kun shi

  6. 1

    Si vous définissez AUTH_USER_MODEL dans settings.py comme ceci:

    AUTH_USER_MODEL = 'custom_user_app_name.User'

    vous devriez mettre cette ligne en commentaire avant de lancer makemigration et migrer commandes. Ensuite, vous pouvez décommenter cette ligne de nouveau.

    OriginalL'auteur Erfan Tahriri

  7. 1

    il suffit de supprimer le fichier sqlite ou exécuter rincer le databse 'python manage.py flush'
    et puis exécutez makemigrations et migrer les commandes respectivement.

    OriginalL'auteur Arun

  8. 1

    lorsque vous créez un nouveau projet Django et exécuter

    python manage.py migrer

    Le Django va créer 10 tables par défaut, y compris un auth_user de table et de deux start avec auth_user.

    lorsque vous souhaitez créer un utilisateur personnalisée modèle hériter de AbstractUser, vous rencontrerez ce problème avec le message d'erreur comme suit:

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

    - Je résoudre ce problème en laissant tomber toute ma base de données, et en créer un nouveau. Et cela remplace les trois tables que j'ai mentionnés.

    Ok, et si je ne veux pas abandonner ma base de données ? Est-il disponible ?

    OriginalL'auteur hcf1425

  9. 0

    D'abord supprimer tous les migrations et la db.sqlite3 fichiers et suivez ces étapes:

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

    Supprimer l'ancien fichier de migration et enfin.

    $ ./manage.py migrate

    OriginalL'auteur shivam singhal

  10. 0

    Si cette exception se révéler à lui-même pendant que vous essayez de créer votre propre modèle d'Utilisateur au lieu de la norme à suivre que l'instruction

    J'ai trouvé mon problème à résoudre par suivre que les instructions étape par étape:

    1. Créer un modèle utilisateur identique à auth.De l'utilisateur, l'appeler à l'Utilisateur (donc
      plusieurs-à-plusieurs tables de garder le même nom) et de définir db_table='auth_user'
      (de sorte qu'il utilise la même table)
    2. De jeter tous vos migrations
    3. Recréer un nouveau jeu de migrations
    4. Sacrifice d'un poulet, peut-être deux si vous êtes anxieux; également faire une sauvegarde de votre base de données
    5. Tronquer la django_migrations table
    6. Faux-appliquer la nouvelle série de migrations
    7. Unset db_table, apporter d'autres modifications au modèle personnalisé, générer des migrations, de les appliquer

    Il est fortement recommandé de le faire sur une base de données qui assure l'
    les contraintes de clé étrangère. Ne pas essayer cela sur SQLite sur votre ordinateur portable et
    attendre il pour travailler sur Postgres sur les serveurs!

    Pourriez-vous ajouter un résumé ou citation de l'article lié à votre réponse?

    OriginalL'auteur N.C.

  11. 0

    lorsque vous créez un nouveau projet et sans apps, vous courez le 

    python manage.py migrate

    le Django va créer 10 tables par défaut.

    Si vous souhaitez créer un modèle utilisateur qui héritent de AbstractUser après, vous rencontrez ce problème, suivez message:

    django.db.les migrations.des exceptions.InconsistentMigrationHistory:
    La Migration admin.0001_initial est appliquée avant sa dépendance
    compte.0001_initial sur la base de données 'par défaut'.

    enfin,
    Je baisse mon ensemble de bases de données et exécuter

    OriginalL'auteur hcf1425