Я пытаюсь отойти от выполнения django миграций, чтобы избежать заблокированных таблиц / простоев во время развертываний, и вместо этого использую SQL через Онлайн-миграции схем .
Я хочу продолжить используя manage.py makemigrations для генерации app/migrations/0001_migratation.py файлов для продолжения отслеживания состояния модели и продолжения выполнения этих миграций на моей машине для разработки. Но я хотел использовать manage.py sqlmigrate <app> <migration.py> для генерации SQL, связанного с моей миграцией, для запуска в моих средах TEST и PROD.
Однако проблема, с которой я сталкиваюсь, заключается в том, что sqlmigrate возвращает только SQL, связанный с файлом миграции python, и не учитывает любые SQL, которые выполняются как часть обратных вызовов, прослушивающих сигналы pre_migration и post_migration , излучаемые во время manage.py migrate.
Одним из примеров такого слушателя является приложение django .contrib.auth , которое гарантирует, что БД находится в согласованном состоянии, добавляя любые недостающие строки в auth_permission и django_content_type таблицы; SQL, для которого не отображается в выходных данных команды manage.py sqlmigrate <app> <migration.py>.
Существует ли стандартный способ захвата SQL этих "побочных эффектов" команды manage.py sqlmigrate для django приложений, которые не запускают миграции в средах без разработки?