Django - South - Is There a way to view the SQL it runs?

Question

Here's what I want to do.

Develop a Django project on a development server with a development database. Run the south migrations as necessary when I change the model.

Save the SQL from each migration, and apply those to the production server when I'm ready to deploy.

Is such a thing possible with South? (I'd also be curious what others do to get your development database changes on production when working with Django)

Answer 1

You can at least inspect the sql generated by doing manage.py migrate --db-dry-run --verbosity=2. This will not do anything to the database and will show all the sql. I would still make a backup though, better safe than sorry.

Answer 2

 python manage.py sqlmigrate <app_label> <migration_name>

Answer 3

You could try logging the SQL queries in db.connection.queries, using a management command that calls the migrate with a dry-run option:

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

Assuming that south puts everything through the usual db interface that should work. There will be a few extra selects in there when it queries the history table.

You'd put that in a management/commands/print_migration_sql.py inside your app and then run it:

python manage.py print_migration_sql

It could probably be easily extended to run this only for specific apps etc

Answer 4

When I need to see the SQL that South generates for debugging or verification I just add the following logging settings to my local_settings.LOGGING.loggers:

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

This is a complete example of the logging setting for 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',
        },
    }
}

This will output everything including the query that South runs to decide what migrations to run:

[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=()"

That and setting verbosity to 2 or 3 is usually more than enough to get a clear picture of what's going on.

Answer 5

I'd either do what Lutger suggested (and maybe write a log parser to strip out just the SQL), or I'd run my migration against a test database with logging enabled on the test DB.

Of course, if you can run it against the test database, you're just a few steps away from validating the migration. If it passes, run it again against production.