190 votes

Django South - la table existe déjà

J'essaie de me lancer dans le Sud. J'avais une base de données existante et j'ai ajouté South ( syncdb , schemamigration --initial ).

Ensuite, j'ai mis à jour models.py pour ajouter un champ et exécutez ./manage.py schemamigration myapp --auto . Il a semblé trouver le champ et m'a dit que je pouvais l'appliquer avec ./manage.py migrate myapp . Mais, en faisant cela, on obtient l'erreur :

django.db.utils.DatabaseError: table "myapp_tablename" already exists

tablename est le premier tableau figurant dans models.py .

J'utilise Django 1.2 et South 0.7.

314voto

Ashok Points 5987

Puisque vous avez déjà créé les tables dans la base de données, il vous suffit d'exécuter la migration initiale en tant que faux.

./manage.py migrate myapp --fake

assurez-vous que le schéma des modèles est le même que celui des tables de la base de données.

41voto

pielgrzym Points 720

Bien que la table "myapp_tablename" existe déjà, l'erreur cesse de se produire après que j'ai fait ./manage.py migrate myapp --fake, le DatabaseError indique no such column : myapp_mymodel.added_field.

J'ai exactement le même problème !

1.Premièrement vérifier le numéro de migration ce qui cause ce problème. Supposons que c'est ça : 0010.

2. vous devez :

./manage.py schemamigration myapp --add-field MyModel.added_field
./manage.py migrate myapp

s'il manque plus d'un champ, vous devez le répéter pour chaque champ.

3. maintenant vous atterrissez avec un tas de nouvelles migrations donc supprimer leurs fichiers de myapp/migrations (0011 et plus si vous avez besoin d'ajouter plusieurs champs).

4. Exécutez ceci :

./manage.py migrate myapp 0010

Maintenant essayez ./manage.py migrate myapp

Si ça ne rate pas, vous êtes prêt. Vérifiez simplement qu'il ne manque aucun champ.

EDIT :

Ce problème peut également se produire lorsque vous avez une base de données de production pour laquelle vous installez South et que la première migration initiale créée dans un autre environnement duplique ce que vous avez déjà dans votre base de données. La solution est ici beaucoup plus simple :

  1. Faux la première migration :

    ./manage migrate myapp 0001 --fake

  2. Roulez avec le reste des migrations :

    ./manage migrate myapp

11voto

ben author Points 1489

Quand j'ai rencontré cette erreur, elle avait une cause différente.

Dans mon cas, South avait, d'une manière ou d'une autre, laissé dans ma base de données une table temporaire vide, qui est utilisée dans le processus d'évaluation de l'efficacité de l'application. _remake_table() . J'avais probablement interrompu une migration d'une manière que je n'aurais pas dû. Quoi qu'il en soit, chaque nouvelle migration suivante, lorsqu'elle appelle _remake_table(), génère l'erreur suivante sqlite3.pypysqlite2.dbapi2.OperationalError: table "_south_new_myapp_mymodel" already exists parce qu'il a fait existe déjà et n'était pas censé être là.

La partie _sud_new m'a semblé étrange, alors j'ai parcouru ma BD, j'ai vu la table _south_new_myapp_mymodel Je me suis gratté la tête, j'ai regardé Source Sud a décidé que c'était de la camelote, a laissé tomber la table, et tout allait bien.

2voto

hobs Points 3020

Si vous avez des problèmes avec vos modèles qui ne correspondent pas à votre base de données, comme @pielgrzym, et que vous voulez migrer automatiquement la base de données pour qu'elle corresponde au dernier fichier models.py (et effacer toutes les données qui ne seront pas recréées par les fixtures lors de la migration de la base de données), vous pouvez le faire. migrate ):

manage.py schemamigration myapp --initial
manage.py migrate myapp --fake
manage.py migrate myapp zero
manage.py migrate myapp

Cette opération ne supprimera et ne recréera que les tables de la base de données qui existent dans votre dernière version de la base de données. models.py Il se peut donc que vous ayez des tables inutilisées dans votre base de données, provenant d'un précédent syncdb ou migrate s. Pour s'en débarrasser, faites précéder toutes ces migrations de :

manage.py sqlclear myapp | manage.py sqlshell

Et si cela laisse encore un peu de CRUFT dans votre base de données, vous devrez effectuer une opération de nettoyage de la base de données. inspectdb et créer le models.py (pour les tables et l'application que vous voulez effacer) avant d'effectuer le processus d'effacement. sqlclear puis restaurez votre fichier models.py original avant de créer le fichier --initial et de migrer vers elle. Tout cela pour éviter de s'embrouiller avec la version particulière de SQL dont votre base de données a besoin.

1voto

Perform these steps in order may help you :

1) python manage.py schemamigration apps.appname --initial

L'étape ci-dessus crée un dossier de migration par défaut.

2) python manage.py migrate apps.appname --fake

génère une fausse migration.

3) python manage.py schemamigration apps.appname --auto

Vous pouvez ensuite ajouter des champs comme vous le souhaitez et exécuter la commande ci-dessus.

4) python manage.py migrate apps.appname

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X