Подтвердить что ты не робот

Django.db.utils.ProgrammingError: отношение уже существует

Я пытаюсь настроить таблицы для нового проекта django (то есть таблицы НЕ уже существуют в базе данных); версия django - 1.7, а конец db - PostgreSQL. Название проекта красное. Результаты попытки миграции:

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 не предназначено, чтобы на самом деле ничего делать, но я использую его в другом приложении, поэтому, когда я пытаюсь выполнить миграцию из этого приложения, я запускаю вышеупомянутую проблему.

Я нашел другие примеры в Интернете людей с подобными проблемами, но ни один из их случаев не применяется, потому что

  • Проблема затрагивает целое отношение, а не только один столбец
  • Я не использую множественное наследование.

Где я должен искать, чтобы найти основную проблему?

4b9b3361

Ответ 3

У вас возникла аналогичная проблема, в конечном итоге удаленные все .py файлы в папке миграции (django 1.7 создает один автоматически), после этого отлично сработал.

Ответ 4

Я столкнулся с подобной проблемой, когда добавил пару новых полей в существующую модель. Я использую Django 1.9, который представил --run-syncdb. Запуск manage.py migrate --run-syncdb исправил мои таблицы.

Ответ 5

Я столкнулся с аналогичными проблемами, когда я изменил имя столбца. Я получал ту же ошибку, что упоминался в трассировке стека, заданной с его вопросом.

Вот что я сделал.

Сначала я запускал поддельные миграции. Затем я удалил запись (миграции, которую я хотел запустить) из таблицы django_migrations и снова выполнил миграцию (на этот раз не подделка).

Изменения появились как ожидалось для меня.

надеюсь, что это будет полезно.

Ответ 6

Теперь (я использую Django 1.9) вы можете сделать:

./manage.py [--database DATABASE] --fake [app_label] [имя_переменной]

Таким образом, вы ориентируетесь на проблему с большей точностью, и вы можете подделать только проблемную миграцию в конкретной базе данных.

Итак, глядя на вопрос, вы могли:

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

Ответ 7

Django предоставляет --fake-initial которую я нашел эффективной для моего использования. Из миграционной документации Django:

--fake-начальная

Позволяет Django пропускать начальную миграцию приложений, если все таблицы базы данных с именами всех моделей, созданных всеми операциями CreateModel в этой миграции, уже существуют. Этот параметр предназначен для использования при первом запуске миграций для базы данных, в которой ранее использовались миграции. Однако этот параметр не проверяет соответствие схемы базы данных за пределами совпадающих имен таблиц, поэтому его можно использовать только в том случае, если вы уверены, что ваша существующая схема совпадает с записанной при первоначальной миграции.

Для моего использования я только что вытащил проект из системы управления версиями и готовился добавить несколько новых полей модели. Я добавил поля, запустил ./manage.py makemigrations и затем попытался запустить ./manage.py migrate что ./manage.py migrate ошибку, поскольку, как и следовало ожидать, многие поля уже существовали в существующей базе данных.

То, что я должен был сделать, - это запустить makemigrations сразу после makemigrations проекта из управления версиями, чтобы создать снимок состояния существующих моделей. Затем следующим шагом будет запуск ./manage.py migrate --fake-initial.

После этого вы можете добавить и makemigrations migrate > migrate как обычно.

ПРИМЕЧАНИЕ: я не знаю, пропустит ли --fake-initial существующие поля и добавит ли новые. Я решил закомментировать новые поля, которые я создал до этого момента, запустить --fake-initial как будто это было первое, что я сделал после извлечения из системы управления версиями, а затем добавил в обновленные поля в следующей миграции.

Другая связанная с этим документация: https://docs.djangoproject.com/en/dev/topics/migrations/#initial-migrations

Ответ 8

Я нашел и решил конкретный пример этой ошибки в проекте Django 1.10, когда я менял поле внешнего ключа с именем member, чтобы указать на другую таблицу. Я менял это в трех разных моделях, и я ударил эту ошибку на всех из них. В моей первой попытке я переименовал member в member_user и попытался создать новое поле member в качестве внешнего ключа, указывающего на новую таблицу, но это не сработало.

Я обнаружил, что когда я переименовал столбец member, он не изменил имя индекса в форме <app>_<model>_<hash>, и когда я попытался создать новый столбец member, он попытался создать такое же имя индекса, хэш-часть имени была одинаковой.

Я решил проблему, создав новое отношение member_user временно и скопировав данные. Это создало новый индекс с другим хэшем. Затем я удалил member и воссоздал его, указав на новую таблицу, и с этим будущим конфликтующим именем индекса. Как только это было сделано, я выполнил шаг RunPython, чтобы заполнить новый столбец member ссылкой на соответствующую таблицу. Я закончил, добавив миграции RemoveField, чтобы очистить временные столбцы member_user.

Мне пришлось разделить мои миграции на два файла, потому что я получил эту ошибку:

psycopg2.OperationalError: не может ALTER TABLE "<table_name > " потому что он имеет ожидающие события запуска

После создания и копирования данных в member_user мне не удалось удалить member в той же транзакции миграции. Это может быть специфическим ограничением postgres, но его легко решить, создав еще одну транзакцию и перемещая все после создания и копирования member_user во вторую миграцию.

Ответ 9

Я нашел эту проблему в web2pyframework в models/config.py.

+ Изменить

settings.base.migrate = True

в конфигурационном файле

settings.base.migrate = False

Задача решена.