2012-03-27 6 views
1

У меня проблема strnage. В моем проекте django есть модуль/приложение myapp. Мой проект использует юг для миграции схемы. На локальном хосте я запустил ./manage.py schemamigration myapp --initial, затем я запустил команду migrate.django + south: команда migrate не создает таблицу в базе данных

Но когда в производственной среде я выполняю команду migrate, это не создает соответствующую базу данных (моделей myapp) в базе данных.

Это странно, потому что если я выполняю migrate --list, myapp должен выполнить миграцию, и все они отмечены (с символом *).

Итак, я думаю об удалении myapp и воссоздании его с нуля (с соответствующими переходами). Есть ли лучшее решение?

EDIT: Я попытался удалить myapp и воссоздать его с нуля. Поэтому я также удалять таблицы MyApp в базе данных (на локальный и на производственном сервере), и в конце концов я выполнил:

schemamigration myapp --initial команда на локальный

migrate myapp команды на локальном хосте

migrate myapp 0001 --fake на производственном сервере

но Юг продолжает не создавать таблицы myapp в базе данных производственного сервера.

+0

Почему вы называете 'migrate ... --fake'? '--fake' делает юг только маркой миграции как успешной, но не касаются фактической схемы БД. – ilvar

ответ

0

Если вы удалили свои таблицы, вы не должны запускать --fake, если только вы не сделали manage.py syncdb. Без таблицы вы можете запустить python manage.py migrate myapp и сделать с ней (или manage.py syncdb). Первая миграция, созданная --initial, содержит в ней инструкции таблицы.

--fake явно указывает югу не делать ничего, кроме того, что он мигрировал (выполнял изменения БД) и маркировал таблицу истории как таковую.

+0

Итак: я удаляю все таблицы (на локальном хосте и на производственном сервере) myapp. Затем я запускаю 'syncdb' или' schemamigration -initial'. Затем я развертываю проект. А потом? Этот метод по-прежнему не создает таблицы базы данных на рабочем сервере. –

+0

@GiovanniChetelodicoafare, если все таблицы удалены, просто запуск 'migrate' создаст таблицы, если в файлах приложений есть файлы миграции' 0001_initial'. Убедитесь, что таблица 'south_migrationhistory' обновлена ​​и не имеет записей для ваших приложений, которые вы перезагружаете. –

+0

Я решил не использовать Юг для myapp, потому что я еще не изменил модели myapp. Таким образом, запуск syncdb на рабочем сервере я решил проблему. Я буду использовать Юг для myapp, если я изменю models.py, и мне нужно выполнить миграцию. Спасибо за помощь. –

0

Я знаю его немного поздно, но у меня была такая же проблема, и я обнаружил, что проблема в том, что мой файл manage.py указывал на неправильный файл настроек, а значит, и на неправильную БД. Убедитесь, что ваш файл manage.py указывает на правильный файл настроек и выполняется миграция в правильный БД. Это может возникнуть, если вы используете несколько файлов manage.py или несколько файлов настроек.

1

Если вы случайно или намеренно сбросили таблицу в своей БД, и вы пытаетесь запустить ./manage migrate myapp Это не создаст выпадающую таблицу в вашей БД. Потому что Юг не касается базы с вашей БД.

Если вы хотите заново создать свой стол. Перенесите свою схему в предыдущую версию и перенесите ее последней. Пожалуйста, используйте приведенный ниже код соответственно.

manage.py migrate myapp 0002 --fake 
manage.py migrate myapp 

примечание: 002 - это ваша предыдущая версия миграции.

Смежные вопросы