Юг - перенос приложения django из sqlite в mysql - PullRequest
Новая
       45

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

3 голосов
/ 11 февраля 2012

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

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

manage.py syncdb --migrate

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

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

Так что я подумал, что все в порядке, я запустил manage.py migrate core 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

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

Ответы [ 2 ]

5 голосов
/ 11 февраля 2012

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

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

python manage.py migrate core zero

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

python manage.py schemamigration --initial core

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

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

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

2 голосов
/ 11 февраля 2012

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

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

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

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

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

python manage.py schemamigration --initial core

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

...