Django - South - Есть ли способ просмотра SQL, который он запускает?

Вот что я хочу сделать.

Разработайте проект Django на сервере разработки с базой данных разработки. Запускайте южные миграции по мере необходимости, когда я меняю модель.

Сохраните SQL из каждой миграции и примените их к производственному серверу, когда я буду готов к развертыванию.

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

Ответы

Ответ 1

Вы можете, по крайней мере, проверить sql, сгенерированный с помощью manage.py migrate --db-dry-run --verbosity=2. Это ничего не сделает с базой данных и покажет все sql. Я все равно сделаю резервную копию, но лучше, чем сожалеть.

Ответ 2

 python manage.py sqlmigrate <app_label> <migration_name>

Ответ 3

Вы можете попробовать выполнить регистрацию SQL-запросов в db.connection.queries, используя команду управления, которая вызывает перенастройку с помощью опции сухого запуска:


from django.core.management.base import BaseCommand
from django import db

class Command(BaseCommand):
    help = 'Output SQL for migration'

    def handle(self, *app_labels, **options):
        # assumes DEBUG is True in settings
        db.reset_queries()

        from django.core.management import call_command
        kw = {'db-dry-run': 1,  'verbosity': 0}
        call_command('migrate', **kw)

        for query in db.connection.queries:
            print query['sql']

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

Поместите это в management/commands/print_migration_sql.py внутри своего приложения, а затем запустите его:


python manage.py print_migration_sql

Вероятно, он может быть легко расширен, чтобы запускать его только для определенных приложений и т.д.

Ответ 4

Когда мне нужно увидеть SQL, который генерирует South для отладки или проверки, я просто добавляю следующие параметры ведения журнала в свой local_settings.LOGGING.loggers:

    'django.db.backends': {
        'handlers': ['console'],
        'level': 'DEBUG',
    },

Это полный пример настройки ведения журнала для юга:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'verbose': {
            'format': '[%(asctime)s] %(levelname)s %(name)s %(lineno)d "%(message)s"'
        },
        'simple': {
            'format': '%(levelname)s %(message)s'
        },
    },
    'filters': {
        'require_debug_false': {
            '()': 'django.utils.log.RequireDebugFalse'
        }
    },
    'handlers': {
        'console': {
            'level': 'DEBUG',
            'class': 'logging.StreamHandler',
            'formatter': 'verbose',
        },
    },
    'loggers': {
        'django': {
            'handlers': ['console'],
            'level': 'DEBUG',
            'propagate': True,
        },
        'django.db.backends': {
            'handlers': ['console'],
            'level': 'DEBUG',
        },
    }
}

Это будет выводить все, включая запрос, который запускает South, чтобы решить, какие миграции выполняться:

[2014-03-12 23:47:31,385] DEBUG django.db.backends 79 "(0.001) SELECT `south_migrationhistory`.`id`, `south_migrationhistory`.`app_name`, `south_migrationhistory`.`migration`, `south_migrationhistory`.`applied` FROM `south_migrationhistory` WHERE `south_migrationhistory`.`applied` IS NOT NULL ORDER BY `south_migrationhistory`.`applied` ASC; args=()"

Это и установка многословия в 2 или 3 обычно более чем достаточно, чтобы получить четкое представление о том, что происходит.

Ответ 5

Я бы либо сделал то, что предложил Лютгер (и, возможно, написал анализатор журналов, чтобы исключить только SQL), или я бы выполнил миграцию с тестовой базой данных с включенным протоколированием в тестовой БД.

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