Блог

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

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

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

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

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

  python manage.py sqlmigrate <app_label> <migration_name>
  

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

 
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']
  

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

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

 
python manage.py print_migration_sql
  

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

Когда мне нужно просмотреть SQL, который South генерирует для отладки или проверки, я просто добавляю следующие параметры ведения журнала в свои local_settings.ВЕДЕНИЕ ЖУРНАЛА.регистраторы:

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

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

 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 обычно более чем достаточно, чтобы получить четкую картину происходящего.

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

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