Блог

Я не уверен на 100%, что делаю это правильно, но я думаю, что обнаружил проблему, из-за которой auth.Permission объекты создаются недостаточно быстро, чтобы миграции могли использовать их при инициализации базы данных с нуля.

Важные детали:

• Я пытаюсь инициализировать Django DB с нуля, используя ./manage.py syncdb --migrate --noinput

• У меня в цепочке 11 миграций

• Первая миграция создает новую модель под названием myapp.CompanyAccount

• 9-я миграция пытается получить разрешение myapp.change_companyaccount с помощью:

p = orm[ "auth.Permission" ].objects.get( codename = "change_companyaccount" )

В этот момент возникает исключение:

django.contrib.auth.models.DoesNotExist: Permission matching query does not exist

Я предположил, что разрешения по умолчанию, которые определены для каждого объекта (согласно http://docs.djangoproject.com/en/dev/topics/auth/#default-permissions ) были бы созданы к моменту завершения первой миграции, но, похоже, что это не так. Если я повторно запущу миграцию после исключения, это сработает во второй раз, потому что, по-видимому, разрешение теперь существует, и 9-я миграция может выполняться без ошибок.

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

Спасибо за любую помощь / совет.

РЕДАКТИРОВАТЬ: В ответ на комментарий Джона ниже я узнал, что будет работать следующая последовательность командной строки:

1. ./manage.py syncdb (это инициализирует таблицы Django по умолчанию)
2. ./manage.py migrate myapp 0001 (это приводит к созданию таблицы CompanyAccount)
3. ./manage.py migrate myapp (это переносит весь путь до конца без ошибок)

К сожалению, пропуск шага # 2 выше означает, что вы получаете то же исключение при миграции 0009, что говорит мне о том, что мое первоначальное подозрение было верным, что разрешения по умолчанию для новых моделей не создаются South немедленно, а каким-то образом помещаются в базу данных только после завершения всей цепочки миграции.

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

Как выясняется, ответ заключается в ручном вызове db.send_pending_create_signals() в какой-то момент, прежде чем пытаться получить доступ к разрешению по умолчанию, поскольку South выполняет этот этап «очистки» только довольно поздно в процессе. Спасибо Эндрю Годвину из South за ответа на это в списке рассылки South здесь:

http://groups.google.com/group/south-users/browse_thread/thread/1de2219fe4f35959

Разве вам не нужно запускать «syncdb» по умолчанию в базе данных virgin, чтобы создать таблицу миграции South; прежде чем вы сможете использовать south. Вы это делаете? Обычно в это время создается таблица разрешений, поскольку у вас есть django.contrib.auth в ваших INSTALLED_APPS.

http://south.aeracode.org/docs/installation.html#configuring-your-django-installation