Вот что я хочу сделать.
Разработайте проект Django на сервере разработки с базой данных разработки. Запускайте южные миграции по мере необходимости, когда я меняю модель.
Сохраните SQL из каждой миграции и примените их к производственному серверу, когда я буду готов к развертыванию.
Возможно ли это с Югом? (Мне также будет любопытно, что делают другие, чтобы получить изменения в базе данных разработки при работе с Django)
Вы можете, по крайней мере, проверить sql, сгенерированный с помощью manage.py migrate --db-dry-run --verbosity=2. Это ничего не сделает с базой данных и покажет все sql. Я все равно сделаю резервную копию, но лучше, чем сожалеть.
python manage.py sqlmigrate <app_label> <migration_name>
Вы можете попробовать выполнить регистрацию 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
Вероятно, он может быть легко расширен, чтобы запускать его только для определенных приложений и т.д.
Когда мне нужно увидеть 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 обычно более чем достаточно, чтобы получить четкое представление о том, что происходит.
Я бы либо сделал то, что предложил Лютгер (и, возможно, написал анализатор журналов, чтобы исключить только SQL), или я бы выполнил миграцию с тестовой базой данных с включенным протоколированием в тестовой БД.
Конечно, если вы можете запустить его против тестовой базы данных, вы всего лишь в нескольких шагах от проверки миграции. Если он пройдет, запустите его снова против производства.