web-dev-qa-db-ja.com

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

私は南で始めようとしています。既存のデータベースがあり、South（syncdb、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を実行しています

djangodjango-south
188
Steve

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

./manage.py migrate myapp --fake

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

311
Ashok

テーブル「myapp_tablename」は、。/ manage.py migrate myapp --fakeを実行した後にエラーが発生して停止しますが、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をインストールする実稼働データベースがあり、他の環境で作成された最初の初期移行がデータベースにすでにあるものと重複している場合にも発生する可能性があります。ここでの解決策ははるかに簡単です：

  1. 最初の移行を偽造する：

    ./manage migrate myapp 0001 --fake

  2. 残りの移行をロールバックします。

    ./myapp migrate myapp

41
pielgrzym

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

私の場合、Southは _ remake_table（） で使用される一時的な空のテーブルを何らかの形でDBに残していました。おそらく、私はあるべきではない方法で移行を中止したのでしょう。いずれの場合も、_remake_table（）を呼び出したときの後続の各新しい移行では、didがすでに存在しているため、エラーsqlite3.pypysqlite2.dbapi2.OperationalError: table "_south_new_myapp_mymodel" already existsがスローされていました。そこにいるはずはありませんでした。

_south_newビットは奇妙に見えたので、DBを閲覧し、テーブル_south_new_myapp_mymodelを見て、頭をかき、 Southのソース を見て、ジャンクだと判断し、テーブルをすべて削除しました。よかった。

10
ben author

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

2
Vijesh Venugopal

@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ファイルに存在するデータベーステーブルのみが削除および再作成されるため、以前のsyncdbsまたはmigratesのガベージテーブルがデータベースに存在する可能性があります。それらを取り除くには、これらすべての移行の前に次を実行します。

manage.py sqlclear myapp | manage.py sqlshell

そして、それでもデータベースにCRUFTが残っている場合は、inspectdbを実行する前に、sqlclearを実行し、そこからmodels.pyファイルを作成する必要があります。 --initial移行を作成して移行する前に、元のmodels.pyを復元します。これらはすべて、データベースが必要とする特定の種類のSQLをいじることを避けるためです。

2
hobs

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

./manage.py convert_to_south myapp

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

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

1
Tommy Strand

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

class Migration(migrations.Migration):

    dependencies = [
        (...)
    ]

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

または

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

class Migration(migrations.Migration):

    dependencies = [
        (...),
    ]

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

もう1つの解決策（一時的な解決策かもしれません）。

$ python manage.py sqlmigrate APP_NAME MIGRATION_NAME

例えば。、。

$ python manage.py sqlmigrate users 0029_auto_20170310_1117

これにより、未加工のSQLクエリのすべての移行がリストされます。既存のテーブルを作成する部分を避けて、実行するクエリを選択できます

0
SuperNova