Юг - миграция приложения django из sqlite в mysql

Question

У меня есть приложение django, и до сих пор я использовал sqlite в качестве базы данных. Теперь, когда это довольно близко к производству, я подумал о переносе всего на mySQL, который будет использоваться на коробке.

Я перенастроить свои настройки в базу данных MySQL и запустить

manage.py syncdb --migrate 

он начал создавать таблицы и все, но не в первом (из 40) миграций со старой ошибкой (can't insert blob without key length и все такое).

Сначала я подумал о том, как вручную фиксировать файлы миграции, но быстро понял, что слишком много ручной работы.

Так что я подумал, хорошо, я побегу manage.py мигрировать ядро ​​0040 (последняя миграция и что будет делать трюк), но он все еще пытается запустить начальный один, а:

File "D:\~Sasha\Portman\core\migrations\0001_initial.py", line 23, in forwards 
    ('name', self.gf('django.db.models.fields.TextField')(unique=True)), 
... error message 

Есть ли способ как-то перенести мои модели без ручной установки начального файла миграции и всей другой магии?

Answer 1

Во-первых, вы не можете выбирать миграции для запуска. migrate core 0040 означает пробег всех маршрутов до 0040. Другими словами, он не запустится 0041, но это будет пробег 0001-0040.

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

python manage.py migrate core zero 

Затем удалите их все (в том числе 0001_initial.py) и просто запустить снова:

python manage.py schemamigration --initial core 

Для регенерации начальной миграции. Он будет основываться на состоянии ваших моделей, что отрицает необходимость 40 миграций.

Всегда рекомендуется сжимать свои миграции таким образом, прежде чем переносить новый код на производство. Поскольку это первый запуск, вы можете удалить их все и начать с нуля, но в будущих итерациях, если вы генерируете 5 миграций в ходе разработки, прежде чем совершить откат до первого из них, удалите те 5 и затем сгенерируйте новую схему. Результатом является только одна миграция со всеми изменениями этих 5. Затем вы можете зафиксировать это и выполнить миграцию в процессе производства.

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

Answer 2

Очень редко я сталкивался с проблемами миграции при развертывании проекта на бэкэнд mysql.

Поскольку развертывается новая копия, у вас есть пара вариантов обходя необходимость запуска всех ваших mightations:

Во-первых, если вы хотите сохранить свою историю миграции как есть, вы можете принудительно syncdb для создания всех ваших таблиц независимо от миграции, а затем запускать поддельные миграции, чтобы обновить вашу новую базу данных.Это будет выглядеть так:

python manage.py syncdb --all 
python manage.py migrate --fake 

В качестве альтернативы, если вы не заботитесь о своих исторических миграций, вы можете очистить старые миграции из (просто удалить их), а затем создать новую начальную миграцию, как:

python manage.py schemamigration --initial core 

Просто убедитесь, что вы также зачистить south_migrationhistory таблицы в базе данных DEV, так что все остается в синхронизации между разработчиком и продом