django.db.utils.ProgrammingError: esiste già una relazione

Question

Sto provando a configurare le tabelle per un nuovo progetto django (ovvero, le tabelle NON esistono già nel database); la versione di django è 1.7 e il back-end db è PostgreSQL. Il nome del progetto è grezzo. I risultati del tentativo di migrazione seguono:

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 

Alcuni punti salienti del file di migrazione:

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

,

L'app crud non è pensata per fare effettivamente qualcosa, ma io la uso un'altra app, quindi quando provo a migrare da quella app, faccio scattare il problema precedente.

ho trovato altri esempi sul web di persone con problemi simili, ma nessuno di loro casi sembrano applicare perché

1. Il problema riguarda un intero rapporto, non solo una colonna
2. Sono non utilizzare l'ereditarietà multipla.

Dove dovrei cercare per trovare il problema sottostante?

Answer 1

State affrontando un problema simile, alla fine cancellato tutti i file .py nella cartella di migrazione (django 1.7 ne crea uno automaticamente), ha funzionato perfettamente dopo.

Answer 2

questo funziona piuttosto bene

./manage.py migrate --fake default 

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

Answer 3

fare `python manage.py migrare --fake' inizialmente. Leggi https://docs.djangoproject.com/en/1.9/ref/django-admin/#django-admin-migrate

Answer 4

Ho riscontrato problemi simili quando ho aggiunto nuovi campi al modello esistente. Sto usando Django 1.9, che è l'opzione introduced--run-syncdb. L'esecuzione di manage.py migrate --run-syncdb ha corretto i miei tavoli.

Answer 5

Ho trovato e risolto un particolare esempio di questo errore in un progetto Django 1.10 mentre stavo modificando un campo di chiave esterna chiamato member per puntare a una tabella diversa. Stavo cambiando questo in tre diversi modelli e ho colpito questo errore su tutti loro. Nel mio primo tentativo ho rinominato in member_user e ho provato a creare un nuovo campo member come chiave esterna che punta alla nuova tabella, ma questo non ha funzionato.

Quello che ho trovato è che quando ho rinominato la colonna member non ha modificato il nome dell'indice nella forma <app>_<model>_<hash> e quando ho provato a creare un nuovo member colonna si è cercato di creare lo stesso nome di indice perché la parte hash del il nome era lo stesso.

Ho risolto il problema creando una nuova relazione member_user temporaneamente e copiando i dati. Questo ha creato un nuovo indice con un diverso hash.Ho quindi eliminato member e lo ho ricreato indicando la nuova tabella e con esso il nome di indice in conflitto. Fatto ciò, ho eseguito il passaggio RunPython per popolare la nuova colonna member con riferimenti alla tabella applicabile. Ho terminato aggiungendo le migrazioni RemoveField per pulire le colonne temporanee member_user.

ho dovuto dividere le mie migrazioni in due file, in quanto ho ricevuto questo errore:

psycopg2.OperationalError: cannot ALTER TABLE "<table_name>" because it has pending trigger events

Dopo la creazione e la copia dei dati in member_user non ero in grado di rimuovere member nella stessa transazione migrazione. Questa potrebbe essere una limitazione postgres specifica, ma è stata facilmente risolta creando un'altra transazione e spostando tutto dopo aver creato e copiato member_user nella seconda migrazione.

Answer 6

Ora (sto usando Django 1.9) si può fare:

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

In questo modo si il problema viene affrontato con maggiore accuratezza e puoi falsificare solo la migrazione problematica sul database specifico.

Così, guardando la questione, si potrebbe:

./manage.py --database predefinita --fake CRUD crud.0001_initial

Answer 7

stavo affrontando i problemi simili, dove ho avuto cambiato il nome della colonna. Stavo ricevendo lo stesso errore menzionato nello stack-trace fornito con la domanda.

Ecco cosa ho fatto.

Ho eseguito prima le migrazioni false. Quindi ho rimosso la migrazione (volevo eseguire) dalla tabella django_migrations e ho eseguito nuovamente le migrazioni (non è falso questa volta).

Le modifiche sono apparse come previsto per me.

spero che questo sia utile.