web-dev-qa-db-fra.com

django 1.7 Migration obtient l'erreur "la table existe déjà"

J'essaie d'appliquer une migration mais j'obtiens l'erreur:

Django.db.utils.OperationalError: (1050, "La table 'clients_client' existe déjà")

Je l'obtenir en émettant la commande suivante:

python manage.py migrate

Ma table client existe déjà. Par conséquent, que dois-je faire pour que la migration le sache, et non pour la sortie d'erreur, et pour exécuter ma modification sur mon modèle?

J'ai exécuté ceci sur mon environnement local avec la base de données locale sans problème. C'est lorsque j'ai pointé ma base de données en production et que j'ai exécuté migrate ci-dessus que j'ai cette erreur.

56
Atma

Si vous avez la table créée dans la base de données, vous pouvez exécuter

python manage.py migrate --fake <appname>

Marquer les migrations comme exécutées sans les exécuter réellement

Ou, si vous souhaitez éviter certaines actions lors de votre migration, vous pouvez modifier le fichier de migration sous le répertoire app/migrations et commenter les opérations que vous ne souhaitez pas effectuer dans l'exécution de la migration.

Docs: https://docs.djangoproject.com/fr/1.8/topics/migrations/#upgrading-from-south ou python manage.py help migrate

116
elmonkeylp

C'est en fait python manage.py migrate --fake <appname>

14
Waqas Javed

Nous pouvons résoudre ce problème de deux manières, comme indiqué dans la réponse: 1.) en modifiant le fichier de migration

Nous avons un dossier de migration créé dans chaque application créée. Dans ces dossiers de migration, le fichier de migration (0001_initial.py est celui initialement créé et tous les autres fichiers dépendants de ce fichier initial seront créés), lors de l'exécution du python manage.py migrate, Pour chaque APP, le fichier de migration s’appliquera s’il est modifié. Nous pouvons voir cette exécution Application sur le terminal après la commande migrate. Si le fichier de migration utilisé pose un problème, nous l’utilisons. pour obtenir l'erreur à ce moment-là. Dans mon/notre cas:

Applying ValetUser.0002_keyroundslots_systemparameters_vehicleparking_vehicleparkingdetails...Traceback (most recent call last):
sqlite3.OperationalError: table "valet_keyroundslots" already exists

Ici, nous pouvons remarquer que le fichier dans lequel nous avons un problème est mentionné, par exemple ValetUser.0002_keyroundslots_systemparameters, afin que nous puissions aller à l'application, puis aux migrations et au fichier 0002, nous pouvons commenter l'opération CreateModel de ce modèle particulier dans laquelle nous sommes confrontés à un problème appliquer des migrations. Exemple:

operations = [
    # migrations.CreateModel(
    #     name='KeyRoundSlots',
    #     fields=[
    #         ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
    #         ('key_round', models.IntegerField()),
    #         ('key_slot', models.IntegerField()),
    #         ('is_available', models.BooleanField()),
    #         ('Valet_id', models.ForeignKey(blank=True, null=True, on_delete=Django.db.models.deletion.CASCADE, related_name='valet_location', to='ValetUser.ValetAt')),
    #     ],
    #     options={
    #         'db_table': 'valet_keyroundslots',
    #     },
    # ),

2.) En appliquant une fausse migration du fichier de migration modifié de l'APP particulière dans laquelle nous sommes confrontés à l'erreur/au problème, --fake appliquera la fausse migration qui n'aura pas d'effet sur la migration déjà appliquée du modèle.

python manage.py migrate --fake <appname>

Les réponses données à Waqas et elmonkeylp sont également correctes, je veux juste expliquer en bref avec l'aide de scénario que nous utilisons

3
Vinay Kumar