web-dev-qa-db-ja.com

django.db.utils.ProgrammingError：関係はすでに存在します

新しいDjangoプロジェクトのテーブルをセットアップしようとしています（つまり、テーブルはデータベースにまだ存在していません）。 Djangoバージョンは1.7で、dbバックエンドはPostgreSQLです。プロジェクトの名前はcrudです。移行試行の結果は次のとおりです。

python manage.py makemigrations crud

Migrations for 'crud':
  0001_initial.py:
    - Create model AddressPoint
    - Create model CrudPermission
    - Create model CrudUser
    - Create model LDAPGroup
    - Create model LogEntry
    - Add field ldap_groups to cruduser
    - Alter unique_together for crudpermission (1 constraint(s))

python manage.py migrate crud

Operations to perform:
  Apply all migrations: crud
Running migrations:
  Applying crud.0001_initial...Traceback (most recent call last):
  File "manage.py", line 18, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python2.7/dist-packages/Django/core/management/__init__.py", line 385, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python2.7/dist-packages/Django/core/management/__init__.py", line 377, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python2.7/dist-packages/Django/core/management/base.py", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/local/lib/python2.7/dist-packages/Django/core/management/base.py", line 338, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python2.7/dist-packages/Django/core/management/commands/migrate.py", line 161, in handle
    executor.migrate(targets, plan, fake=options.get("fake", False))
  File "/usr/local/lib/python2.7/dist-packages/Django/db/migrations/executor.py", line 68, in migrate
    self.apply_migration(migration, fake=fake)
  File "/usr/local/lib/python2.7/dist-packages/Django/db/migrations/executor.py", line 102, in apply_migration
    migration.apply(project_state, schema_editor)
  File "/usr/local/lib/python2.7/dist-packages/Django/db/migrations/migration.py", line 108, in apply
    operation.database_forwards(self.app_label, schema_editor, project_state, new_state)
  File "/usr/local/lib/python2.7/dist-packages/Django/db/migrations/operations/models.py", line 36, in database_forwards
    schema_editor.create_model(model)
  File "/usr/local/lib/python2.7/dist-packages/Django/db/backends/schema.py", line 262, in create_model
    self.execute(sql, params)
  File "/usr/local/lib/python2.7/dist-packages/Django/db/backends/schema.py", line 103, in execute
    cursor.execute(sql, params)
  File "/usr/local/lib/python2.7/dist-packages/Django/db/backends/utils.py", line 82, in execute
    return super(CursorDebugWrapper, self).execute(sql, params)
  File "/usr/local/lib/python2.7/dist-packages/Django/db/backends/utils.py", line 66, in execute
    return self.cursor.execute(sql, params)
  File "/usr/local/lib/python2.7/dist-packages/Django/db/utils.py", line 94, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/usr/local/lib/python2.7/dist-packages/Django/db/backends/utils.py", line 66, in execute
    return self.cursor.execute(sql, params)
Django.db.utils.ProgrammingError: relation "crud_crudpermission" already exists

移行ファイルからのいくつかのハイライト：

dependencies = [
    ('auth', '0001_initial'),
    ('contenttypes', '0001_initial'),
]
    migrations.CreateModel(
        name='CrudPermission',
        fields=[
            ('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
            ('_created_by', models.CharField(default=b'', max_length=64, null=True, editable=False, blank=True)),
            ('_last_updated_by', models.CharField(default=b'', max_length=64, null=True, editable=False, blank=True)),
            ('_created', models.DateTimeField(null=True, editable=False, blank=True)),
            ('_last_updated', models.DateTimeField(null=True, editable=False, blank=True)),
            ('domain', models.CharField(max_length=32, choices=[(b'town', b'Town'), (b'boe', b'BOE'), (b'police', b'Police')])),
            ('ldap_group', models.CharField(max_length=128, verbose_name=b'LDAP group')),
            ('can_add', models.BooleanField(default=False, verbose_name=b'add')),
            ('can_change', models.BooleanField(default=False, verbose_name=b'change')),
            ('restrict_change_to_own', models.BooleanField(default=False)),
            ('can_delete', models.BooleanField(default=False, verbose_name=b'delete')),
            ('restrict_delete_to_own', models.BooleanField(default=False)),
            ('models', models.ManyToManyField(to='contenttypes.ContentType', null=True, blank=True)),
        ],
        options={
            'verbose_name': 'CRUD permission',
        },
        bases=(models.Model,),
    ),
    migrations.AlterUniqueTogether(
        name='crudpermission',
        unique_together=set([('ldap_group', 'can_add', 'can_change', 'can_delete', 'domain')]),
    )

、

Crudアプリは実際に何もするものではありませんが、別のアプリを使用するため、そのアプリから移行しようとすると、上記の問題が発生します。

同様の問題を持つ人々のウェブ上で他の例を見つけましたが、彼らのケースはどれも当てはまらないようです。

  1. 問題は1つの列だけでなく、リレーション全体に影響します
  2. 多重継承を使用していません。

根本的な問題を見つけるために次にどこを見るべきですか？

pythondjangopostgresqlubuntu
59
quindraco

これはかなりうまくいきます

./manage.py migrate --fake default

ソース：- https://github.com/nijel/weblate/issues/587

61
trex

最初にpython manage.py migrate --fakeを実行します。

読む https://docs.djangoproject.com/en/1.9/ref/Django-admin/#Django-admin-migrate

30
Mudassar Hashmi

同様の問題に直面して、最終的に移行フォルダー内のすべての.pyファイルを削除し（Django 1.7が自動的に作成します）、その後完全に機能しました。

6
Rickka

既存のモデルにいくつかの新しいフィールドを追加すると、同様の問題に直面しました。私はDjango 1.9を使用していますが、これは 導入済み--run-syncdbオプションです。 manage.py migrate --run-syncdbを実行すると、テーブルが修正されました。

5
roboslone

列名を変更した同様の問題に直面していました。私は彼の質問で提供されたスタックトレースで言及されたのと同じエラーを受け取っていました。

これが私がしたことです。

最初に偽の移行を実行しました。次に、（実行したい移行）エントリをDjango_migrationsテーブルから削除し、移行を再度実行しました（今回は偽物ではありません）。

予想どおり変更が表示されました。

これが役立つことを願っています。

4
Vishal Mopari

Djangoには--fake-initialオプションが用意されており、これを使用すると効果的です。 Django Migration Documentation から：

-偽の初期

その移行のすべてのCreateModel操作によって作成されたすべてのモデルの名前を持つすべてのデータベーステーブルが既に存在する場合、Djangoがアプリの初期移行をスキップできるようにします。このオプションは、移行の使用が既存のデータベースに対して最初に移行を実行するときに使用することを目的としています。ただし、このオプションは、一致するテーブル名以外の一致するデータベーススキーマをチェックしないため、既存のスキーマが最初の移行で記録されたものと一致する場合にのみ安全に使用できます。

使用するために、バージョン管理からプロジェクトを取得し、いくつかの新しいモデルフィールドを追加する準備をしていました。フィールドを追加し、./manage.py makemigrationsを実行し、./manage.py migrateを実行しようとしましたが、予想どおり、多くのフィールドが既存のデータベースにすでに存在していたため、エラーがスローされました。

私がすべきだったのは、バージョン管理からプロジェクトをプルした直後にmakemigrationsを実行して、既存のモデルの状態のスナップショットを作成することでした。次に、./manage.py migrate --fake-initialを実行することが次のステップになります。

その後、追加して、通常どおりmakemigrations> migrateを追加できます。

注：--fake-initialが既存のフィールドをスキップし、add newもの。その時点までに作成した新しいフィールドをコメントアウトすることを選択し、--fake-initialを実行して、バージョン管理からプルした後の最初の操作であるかのように実行しましたthen次の移行で更新されたフィールドに追加されました。

その他の関連ドキュメント： https://docs.djangoproject.com/en/dev/topics/migrations/#initial-migrations

3
theeastcoastwest

これで（Django 1.9を使用しています）、次のように作成できます。

./ manage.py [--database DATABASE] --fake [app_label] [migration_name]

このようにして、より正確に問題をターゲットにし、特定のデータベースで問題のある移行のみを偽造できます。

したがって、質問を見て、次のことができます。

./ manage.py --database default --fake crud crud.0001_initial

3
Raydel Miranda

この問題はweb2pyframeworkのmodels/config.pyで見つかりました。

変化する

settings.base.migrate = True

設定ファイルに

settings.base.migrate = False

問題が解決しました。

1
R.kiani

memberという名前の外部キーフィールドを別のテーブルを指すように変更しているときに、Django 1.10プロジェクトでこのエラーの特定の例を見つけて解決しました。 3つの異なるモデルでこれを変更していましたが、すべてのモデルでこのエラーが発生しました。最初の試行で、memberの名前をmember_userに変更し、新しいテーブルを指す外部キーとして新しいフィールドmemberを作成しようとしましたが、これは機能しませんでした。

私が見つけたのは、member列の名前を変更したとき、<app>_<model>_<hash>形式のインデックス名は変更されず、新しいmember列を作成しようとしても同じものを作成しようとしたことです。名前のハッシュ部分が同じだったため、インデックス名。

新しいmember_user関係を一時的に作成し、データをコピーすることで問題を解決しました。これにより、異なるハッシュを持つ新しいインデックスが作成されました。次にmemberを削除し、新しいテーブルとそれと競合するインデックス名を指すように再作成しました。それが完了したら、RunPythonステップを実行して、新しいmember列に適切なテーブルへの参照を追加しました。 RemoveFieldマイグレーションを追加して、一時的なmember_user列をクリーンアップしました。

このエラーを受け取ったため、移行を2つのファイルに分割する必要がありました。

psycopg2.OperationalError：保留中のトリガーイベントがあるため、TABLE "<table_name>"を変更できません

データを作成してmember_userにコピーした後、同じ移行トランザクションでmemberを削除できませんでした。これはpostgres固有の制限かもしれませんが、別のトランザクションを作成し、member_userを作成して2番目の移行にコピーした後にすべてを移動することで簡単に解決しました。

1
Shaun Kruger