Юг не будет создавать или применять миграции для существующего приложения с изменениями для переноса

Я использую South для создания и применения миграций, а не управляю этим сам. К сожалению, Юг на самом деле отказывается делать что-либо. Расшифровка ниже:

[graffias:~/testing.tustincommercial.com/oneclickcos]$ python ./manage.py schemamigration mainapp --auto
You cannot use --auto on an app with no migrations. Try --initial.
[graffias:~/testing.tustincommercial.com/oneclickcos]$ python ./manage.py schemamigration mainapp --initial
 + Added model mainapp.CompanyUK
 + Added model mainapp.CompanyName
 + Added model mainapp.Individual
 + Added model mainapp.Director
 + Added model mainapp.DirectorsIndividual
 + Added model mainapp.DirectorsCorporate
 + Added model mainapp.ShareCapitalClass
 + Added model mainapp.Member
 + Added model mainapp.MembersIndividual
 + Added model mainapp.MemberGeneric
 + Added model mainapp.CompanyManager
 + Added model mainapp.PendingRegistration
 + Added model mainapp.PendingAuthorisation
Created 0001_initial.py. You can now apply this migration with: ./manage.py migrate mainapp
[graffias:~/testing.tustincommercial.com/oneclickcos]$ python ./manage.py migrate mainapp
Running migrations for mainapp:
- Nothing to migrate.
 - Loading initial data for mainapp.
No fixtures found.
[graffias:~/testing.tustincommercial.com/oneclickcos]$

Как видите, Юг думает, что тут нечего делать. Однако последние три модели совершенно новые и не имеют таблицы в базе данных.

Могу ли я что-нибудь сделать, кроме как отключить базу данных, чтобы Юг снова заработал?

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


python django migration django-south
person Marcin    schedule 04.09.2011    source источник

Ответы (4)


arrow_upward
9
arrow_downward

Я полагаю, вы навлекли на себя неприятности, не начав с ./manage.py convert_to_south mainapp. Возможно, вы можете исправить это, выполнив:

(1) Заставьте Юга поверить, что вы не выполнили первую миграцию, поэтому перейдите к нулю

./manage.py migrate --fake mainapp zero

(2) Мигрируйте по-настоящему на первую миграцию.

./manage.py migrate mainapp

Но что я могу сделать из вашего вопроса, у вас уже были некоторые модели в вашей базе данных, сделанные без Юга, иначе вам не пришлось бы использовать --initial. Если это так, он, вероятно, будет жаловаться на уже существующие столбцы.

Вы можете изменить эту ситуацию:

(1) Удаление первой схемы миграции путем удаления mainapp/migrations/0001_initial.py. Вам не нужно возиться с таблицей базы данных South напрямую, --delete-ghost-migrations позаботится об этом.

(2) ./manage.py syncdb Юг ожидает, что база данных будет синхронизирована с моделями.

(3) ./manage.py convert_to_south mainapp фактически позволить Югу управлять базой данных и миграциями.

(4) ./manage.py migrate --delete-ghost-migrations mainapp для перехода к первой миграции и удаления старой первой миграции, которую вы удалили из миграции/ из базы данных

person Density 21.5    schedule 04.09.2011
comment
То же. Это действительно помогло мне, когда я сделал sqlreset для локального удаления таблиц, а потом Саут продолжал говорить мне, что мне нечего мигрировать. - person 3cheesewheel; 18.10.2013

arrow_upward
2
arrow_downward

От отдела грязных хаков:

Этот процесс решил мою проблему, но вряд ли он элегантен.

(1) Удалите все миграции в затронутом приложении (rm mainapp/migrations/*)

(2) Удалите файл models.py и замените его пустым файлом (mv mainapp/models.py .; rm mainapp/*.pyc; touch mainapp/models.py)

(3) Создайте начальную миграцию, которая ничего не делает (python ./manage.py schemamigration mainapp --initial), и примените ее (python ./manage.py migrate mainapp)

(4) Восстановите свои модели и создайте миграцию, которая воссоздаст все (rm mainapp/models.py; mv models.py mainapp/; python ./manage.py schemamigration mainapp --auto)

(5) ПЕРЕД запуском новой миграции отредактируйте ее, чтобы закомментировать все изменения, которые на самом деле не являются новыми изменениями. В качестве альтернативы запустите его и сделайте так, чтобы он не работал с реально существующими таблицами, а затем закомментируйте все.

(6) Примените свою миграцию, чтобы перевести юг в нечто вроде нормального состояния (и внесите свои изменения, если вы следовали моему рекомендованному курсу в шаге (5): python ./manage.py migrate mainapp)

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

person Marcin    schedule 04.09.2011

arrow_upward
2
arrow_downward

Также обратите внимание, что если вы используете кеш QuerySet, например Johnny Cache, удаление истории миграции из базы данных не поможет, вам нужно либо убить memcached: killall memcached, либо для проектов в производстве вам необходимо аннулировать таблицу south_migrationhistory, используя следующее, используя python manage.py shell:

from johnny.cache import invalidate
invalidate('south_migrationhistory')

Так было со мной.

person hurturk    schedule 10.02.2013

arrow_upward
1
arrow_downward

Если вы уже создали базу данных, вам нужно использовать:

python manage.py convert_to_south myapp

вместо схемамиграции. Если уже слишком поздно для этого, и вас не волнуют данные в вашей базе данных, запустите:

  1. очистить базу данных с помощью: python manage.py flush
  2. удалить старые миграции с помощью: sudo rm /path/to/myapp/migrations/*.*
  3. python manage.py syncdb
  4. sudo python manage.py convert_to_south myapp
person johnmic07    schedule 16.12.2013
comment
Это не отвечает на вопрос. - person Marcin; 16.12.2013