Работает ли юг Джанго (инструмент миграции) для innodb?

Question

$ py manage.py  migrate turkey
Running migrations for turkey:
 - Migrating forwards to 0001_initial.
 > turkey:0001_initial
 ! Error found during real run of migration! Aborting.

 ! Since you have a database that does not support running
 ! schema-altering statements in transactions, we have had 
 ! to leave it in an interim state between migrations.

! You *might* be able to recover with:   = DROP TABLE `turkey_demorecs` CASCADE; []

 ! The South developers regret this has happened, and would
 ! like to gently persuade you to consider a slightly
 ! easier-to-deal-with DBMS.
 ! NOTE: The error which caused the migration to fail is further up.

Почему-то я получаю это, когда пытаюсь это сделать. Но другие мои настройки находятся в MyISAM.

Почему это не работает в Innodb?

Answer 1

InnoDB имеет ограничения на внешние ключи, которые гарантируют, что вы не нарушаете модель базы данных при выполнении миграции. (см. http://dev.mysql.com/doc/refman/5.5/en/innodb-foreign-key-constraints.html)

MyISAM не имеет встроенной поддержки ограничений (хотя кажется, что вы можете реализовать это, если решите сделать http://dev.mysql.com/tech-resources/articles/mysql-enforcing-foreign-keys.html)

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

Answer 2

См. Также https://code.djangoproject.com/wiki/AlterModelOnSyncDB

У меня была такая же ошибка, возникающая со мной при работе с настройкой mysql, чей механизм хранения таблиц по умолчанию - MyISAM, и я хотел использовать InnoDB (используя рецепт, указанный в ссылке выше, мы использовали сигнал post_syncdb вызвать код преобразования). Однако при использовании South для создания новых таблиц они сначала создавались с использованием механизма MyISAM, а затем преобразовывались. Я ошибочно полагал, что таблицы InnoDB не делали то, что они должны были делать, когда на самом деле это были MyISAM; поскольку таблица была преобразована по сигналу, любая ошибка миграции не сможет быть применена: - /

Если вам нужно использовать или создавать таблицы InnoDB, где по умолчанию используется MyISAM, это можно решить с помощью:

# add at the beginning of your migration
if db.backend_name == 'mysql':
   db.execute('SET storage_engine=INNODB')

или, если вы не возражаете, удар по производительности:

# add this to settings.py
DATABASE_OPTIONS = {
   "init_command": "SET storage_engine=INNODB", # XXX: performance hit...
}

Answer 3

Вы можете попробовать добавить к своей первой миграции:

if db.backend_name == 'mysql':
    db.execute('SET foreign_key_checks=0')

Это отключит ограничения проверки внешнего ключа.

Вам не нужно устанавливать его обратно в 1, поскольку это переменная сеанса.

Кстати, это не сработает, если вы установите значение 0 в начале и обратно в 1 в конце метода миграции, потому что south генерирует с ними SQL, но выполняет его, когда они возвращаются.

Answer 4

Да, Юг поддерживает InnoDB.Можете ли вы удалить содержимое вашей папки «migrations» и повторно запустить schemamigration, перенести и опубликовать результаты и содержимое файла 0001_initial здесь?PS: сначала убедитесь, что у вас есть резервная копия папки миграции или в системе контроля версий.

rm -fr app/migrations/*
./manage.py schemamigration app --initial
./manage.py migrate app