Ответ 1
Это работает довольно хорошо
./manage.py migrate --fake default
Источник: - https://github.com/nijel/weblate/issues/587
Я пытаюсь настроить таблицы для нового проекта 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 не предназначено, чтобы на самом деле ничего делать, но я использую его в другом приложении, поэтому, когда я пытаюсь выполнить миграцию из этого приложения, я запускаю вышеупомянутую проблему.
Я нашел другие примеры в Интернете людей с подобными проблемами, но ни один из их случаев не применяется, потому что
Где я должен искать, чтобы найти основную проблему?
Это работает довольно хорошо
./manage.py migrate --fake default
Источник: - https://github.com/nijel/weblate/issues/587
Сделайте ли python manage.py migrate --fake
.
Прочитайте https://docs.djangoproject.com/en/1.9/ref/django-admin/#django-admin-migrate.
У вас возникла аналогичная проблема, в конечном итоге удаленные все .py файлы в папке миграции (django 1.7 создает один автоматически), после этого отлично сработал.
Я столкнулся с подобной проблемой, когда добавил пару новых полей в существующую модель. Я использую Django 1.9, который представил --run-syncdb
. Запуск manage.py migrate --run-syncdb
исправил мои таблицы.
Я столкнулся с аналогичными проблемами, когда я изменил имя столбца. Я получал ту же ошибку, что упоминался в трассировке стека, заданной с его вопросом.
Вот что я сделал.
Сначала я запускал поддельные миграции. Затем я удалил запись (миграции, которую я хотел запустить) из таблицы django_migrations и снова выполнил миграцию (на этот раз не подделка).
Изменения появились как ожидалось для меня.
надеюсь, что это будет полезно.
Теперь (я использую Django 1.9) вы можете сделать:
./manage.py [--database DATABASE] --fake [app_label] [имя_переменной]
Таким образом, вы ориентируетесь на проблему с большей точностью, и вы можете подделать только проблемную миграцию в конкретной базе данных.
Итак, глядя на вопрос, вы могли:
./manage.py --database default --fake crud crud.0001_initial
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
Я нашел и решил конкретный пример этой ошибки в проекте 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
во вторую миграцию.
Я нашел эту проблему в web2pyframework
в models/config.py
.
+ Изменить
settings.base.migrate = True
в конфигурационном файле
settings.base.migrate = False
Задача решена.