Django South-テーブルはすでに存在します

私はサウスから始めようとしています。既存のデータベースがありsyncdb、South（、schemamigration --initial）。

次に、models.pyフィールドを追加するために更新して実行しました./manage.py schemamigration myapp --auto。フィールドを見つけたようで、でこれを適用できると言いました./manage.py migrate myapp。しかし、それを行うとエラーが発生しました：

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

tablenameに記載されている最初のテーブルmodels.pyです。

Django 1.2、South 0.7を実行しています

データベースにテーブルがすでに作成されているので、最初の移行を偽として実行するだけです

./manage.py migrate myapp --fake

モデルのスキーマがデータベース内のテーブルのスキーマと同じであることを確認してください。

./manage.py migrate myapp --fakeを実行した後、テーブル "myapp_tablename"にはすでにエラーが発生して停止しますが、DatabaseErrorにはそのような列は表示されません：myapp_mymodel.added_field。

まったく同じ問題が発生しました！

1.まず、これを引き起こしている移行番号を確認します。それが0010であると仮定しましょう。

2.する必要があります：

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

欠落しているフィールドが複数ある場合は、フィールドごとに繰り返す必要があります。

3.多くの新しい移行が発生したので、それらのファイルを削除します、myapp / migrationsからを（複数のフィールドを追加する必要がある場合は0011とさらに）。

4.これを実行します：

./manage.py migrate myapp 0010

./manage.py migrate myappを試してください

失敗しなければ準備は完了です。欠落していないフィールドがないか再確認してください。

編集：

この問題は、Southをインストールする運用データベースがあり、他の環境で作成された最初の初期移行が、すでにdbにあるものと重複している場合にも発生する可能性があります。解決策はここではるかに簡単です：

1. 最初の移行の偽物：

   ./manage migrate myapp 0001 --fake

2. 残りの移行でロール：

   ./manage migrate myapp

このエラーに遭遇したときは、別の原因がありました。

私の場合、サウスはどういうわけか私のDBに_remake_table（）で使用される一時的な空のテーブルを残していました。おそらく、私がすべきでない方法で移行を中止しました。いずれの場合でも、_remake_table（）を呼び出すと、それ以降の新しい移行のたびにエラーがスローさsqlite3.pypysqlite2.dbapi2.OperationalError: table "_south_new_myapp_mymodel" already existsれていました。すでに存在していて、そこにあるとは想定されていなかったためです。

_south_newビットは私には奇妙に見えたので、私は自分のDBを参照し、テーブルを見て_south_new_myapp_mymodel、頭をかき、サウスのソースを見て、それがジャンクであると判断し、テーブルをドロップし、すべてが順調でした。

@pielgrzymのようにモデルがデータベースに一致しない問題があり、データベースを自動的に移行して最新のmodels.pyファイルに一致させる（および中にフィクスチャによって再作成されないデータを消去するmigrate）場合：

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

これにより、最新のmodels.pyファイルに存在するデータベーステーブルのみが削除および再作成されるため、データベースに以前syncdbのsまたはmigratesのガベージテーブルが存在する可能性があります。それらを取り除くには、これらすべての移行の前に以下を実行します。

manage.py sqlclear myapp | manage.py sqlshell

それでもデータベースにCRUFTが残っている場合は、を実行する前にinspectdb、models.pyからファイルを作成し（消去するテーブルとアプリ用に）sqlclear、元のmodels.pyを復元する必要があります。--initialマイグレーションを作成してそこにマイグレーションします。これはすべて、データベースに必要な特定のSQLの種類をいじるのを避けるためです。

Perform these steps in order may help you：

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

上記の手順では、デフォルトで移行フォルダが作成されます。

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

偽の移行を生成します。

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

次に、必要に応じてフィールドを追加し、上記のコマンドを実行できます。

4）python manage.py migrate apps.appname

既存のデータベースとアプリがある場合は、南変換コマンドを使用できます

./manage.py convert_to_south myapp

これは、すでにデータベースにあるものに変更を加える前に適用する必要があります。

convert_to_southコマンドは、最初に実行したマシンでのみ完全に機能します。VCSへの初期移行をコミットしたら./manage.py migrate myapp 0001 --fake、コードベースのコピーがあるすべてのマシンで実行する必要があります（最初にモデルとスキーマが最新であることを確認してください）。ref：http : //south.readthedocs.org/en/latest/convertinganapp.html

一時的な解決策として、移行スクリプトでテーブルの作成をコメント化できます。

class Migration(migrations.Migration):

    dependencies = [
        (...)
    ]

    operations = [
        #migrations.CreateModel(
        #    name='TABLE',
        #    fields=[
        #            ....
        #            ....
        #    ],
        #),
        ....
        ....

または

既存のテーブルに行が含まれていない（空の）場合は、以下のようにテーブルを削除することを検討してください。（この修正は、テーブルに行が含まれていない場合にのみお勧めします）。また、createModel操作の前にこの操作を確認してください。

class Migration(migrations.Migration):

    dependencies = [
        (...),
    ]

    operations = [
        migrations.RunSQL("DROP TABLE myapp_tablename;")
    ]

もう1つの解決策（おそらく一時的な解決策）。

$ python manage.py sqlmigrate APP_NAME MIGRATION_NAME

例えば。、。

$ python manage.py sqlmigrate users 0029_auto_20170310_1117

これにより、すべての移行が生のSQLクエリで一覧表示されます。既存のテーブルを作成する部分を避けて実行するクエリを選択できます