it-swarm.com.de

django.db.utils.ProgrammingError: Beziehung existiert bereits

Ich versuche, die Tabellen für ein neues Django Projekt einzurichten (dh die Tabellen sind NICHT bereits in der Datenbank vorhanden); die Django Version) ist 1.7 und das DB-Back-End ist PostgreSQL. Der Name des Projekts ist roh. Die Ergebnisse des Migrationsversuchs sind wie folgt:

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

Einige Highlights aus der Migrationsdatei:

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')]),
    )

,

Die Crud-App soll eigentlich nichts tun, aber ich verwende sie als andere App. Wenn ich also versuche, von dieser App zu migrieren, löse ich das oben genannte Problem aus.

Ich habe andere Beispiele im Internet von Leuten mit ähnlichen Problemen gefunden, aber keiner ihrer Fälle scheint darauf zuzutreffen

  1. Das Problem betrifft eine ganze Beziehung, nicht nur eine Spalte
  2. Ich verwende keine Mehrfachvererbung.

Wo soll ich nachsehen, um das zugrunde liegende Problem zu finden?

59
quindraco

Das funktioniert ganz gut

./manage.py migrate --fake default

Quelle: - https://github.com/nijel/weblate/issues/587

61
trex

Machen python manage.py migrate --fake anfänglich.

Lesen Sie https://docs.djangoproject.com/en/1.9/ref/Django-admin/#Django-admin-migrate

30
Mudassar Hashmi

Bei einem ähnlichen Problem wurden schließlich alle .py-Dateien im Migrationsordner gelöscht (Django 1.7 erstellt automatisch eine). Danach funktionierte es einwandfrei.

6
Rickka

Ich hatte ein ähnliches Problem, als ich ein paar neue Felder zum bestehenden Modell hinzufügte. Ich verwende Django 1.9, das eingeführt--run-syncdb Möglichkeit. Laufen manage.py migrate --run-syncdb habe meine Tische repariert.

5
roboslone

Ich war mit ähnlichen Problemen konfrontiert, bei denen ich den Spaltennamen geändert hatte. Es wurde derselbe Fehler gemeldet, der in der mit der Frage gelieferten Stapelverfolgung erwähnt wurde.

Hier ist was ich getan habe.

Ich habe zuerst gefälschte Migrationen durchgeführt. Dann entfernte ich den Eintrag (Migrationen, die ich ausführen wollte) aus der Tabelle Django_migrations und führte die Migrationen erneut aus (diesmal keine Fälschung).

Änderungen erschienen wie erwartet für mich.

hoffe das ist hilfreich.

4
Vishal Mopari

Django bietet eine --fake-initial - Option, die ich für meine Verwendung als effektiv empfunden habe. Aus der Django-Migrationsdokumentation :

--Fake-Initiale

Ermöglicht Django die anfängliche Migration einer App zu überspringen, wenn bereits alle Datenbanktabellen mit den Namen aller Modelle vorhanden sind, die von allen CreateModel-Vorgängen in dieser Migration erstellt wurden. Diese Option ist für die erstmalige Ausführung von Migrationen für a vorgesehen Datenbank, die die Verwendung von Migrationen vorbestanden hat: Diese Option prüft jedoch nicht, ob das Datenbankschema über die übereinstimmenden Tabellennamen hinaus übereinstimmt, und ist daher nur dann sicher zu verwenden, wenn Sie sicher sind, dass Ihr vorhandenes Schema mit dem übereinstimmt, was bei der ursprünglichen Migration aufgezeichnet wurde.

Ich hatte gerade ein Projekt aus der Versionskontrolle gezogen und bereitete mich darauf vor, einige neue Modellfelder hinzuzufügen. Ich habe die Felder hinzugefügt, ./manage.py makemigrations Ausgeführt und dann versucht, ./manage.py migrate Auszuführen, was den Fehler verursachte, da erwartungsgemäß viele der Felder bereits in der vorhandenen Datenbank vorhanden waren.

Ich hätte sofort nach dem Abrufen des Projekts aus der Versionskontrolle makemigrations ausführen sollen, um eine Momentaufnahme des Status vorhandener Modelle zu erstellen. Dann wäre die Ausführung von ./manage.py migrate --fake-initial Der nächste Schritt.

Danach können Sie wie gewohnt hinzufügen und makemigrations> migrate.

HINWEIS: Ich weiß nicht, ob ein --fake-initial Vorhandene Felder überspringen würde und neue hinzufügen. Ich entschied mich, die neuen Felder, die ich bis zu diesem Zeitpunkt erstellt hatte, zu kommentieren und den --fake-initial Auszuführen, als wäre es das erste, was ich nach dem Abrufen der Versionskontrolle tat, dann in aktualisierten Feldern bei der nächsten Migration hinzugefügt.

Weitere zugehörige Dokumentation: https://docs.djangoproject.com/en/dev/topics/migrations/#initial-migrations

3

Jetzt (ich verwende Django 1.9)) kannst du machen:

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

Auf diese Weise zielen Sie genauer auf das Problem ab und können nur die problematische Migration in der spezifischen Datenbank vortäuschen.

Wenn Sie sich die Frage ansehen, könnten Sie:

./ manage.py - Datenbankstandard --fake crud crud.0001_initial

3
Raydel Miranda

Ich fand dieses Problem in web2pyframework im models/config.py.

Veränderung

settings.base.migrate = True

auf Konfigurationsdatei zu

settings.base.migrate = False

Problem gelöst.

1
R.kiani

Ich habe ein bestimmtes Beispiel für diesen Fehler in einem Django 1.10-Projekt gefunden und gelöst, als ich ein Fremdschlüsselfeld namens member geändert habe, um auf eine andere Tabelle zu verweisen. Ich habe dies geändert Bei drei verschiedenen Modellen trat dieser Fehler bei allen auf. Bei meinem ersten Versuch habe ich member in member_user umbenannt und versucht, ein neues Feld member als Fremdschlüssel zu erstellen auf den neuen Tisch zeigen, aber das hat nicht funktioniert.

Was ich gefunden habe, ist, dass beim Umbenennen der Spalte member der Indexname in der Form <app>_<model>_<hash> Nicht geändert wurde und dass ich versucht habe, eine neue Spalte member zu erstellen Erstellen Sie denselben Indexnamen, da der Hash-Teil des Namens identisch war.

Ich habe das Problem behoben, indem ich vorübergehend eine neue member_user - Beziehung erstellt und die Daten kopiert habe. Dadurch wurde ein neuer Index mit einem anderen Hash erstellt. Ich habe dann member gelöscht und es neu erstellt, indem ich auf die neue Tabelle und damit auf den möglicherweise in Konflikt stehenden Indexnamen zeigte. Danach habe ich den Schritt RunPython ausgeführt, um die neue Spalte member mit Verweisen auf die entsprechende Tabelle zu füllen. Abschließend habe ich RemoveField Migrationen hinzugefügt, um die temporären Spalten member_user Zu bereinigen.

Ich musste meine Migrationen in zwei Dateien aufteilen, da ich diesen Fehler erhielt:

psycopg2.OperationalError: TABLE "<Tabellenname>" kann nicht geändert werden, da anstehende Triggerereignisse vorliegen

Nach dem Erstellen und Kopieren der Daten in member_user Konnte ich member in derselben Migrationstransaktion nicht entfernen. Dies kann eine postgres-spezifische Einschränkung sein, die jedoch leicht behoben werden kann, indem eine weitere Transaktion erstellt und alles nach dem Erstellen und Kopieren von member_user In die zweite Migration verschoben wird.

1
Shaun Kruger