Django - South - 有没有办法查看它运行的 SQL?

发布于 2024-11-04 18:53:44 字数 174 浏览 4 评论 0原文

这就是我想做的。

在具有开发数据库的开发服务器上开发 Django 项目。当我更改模型时,根据需要运行南方迁移。

保存每次迁移的 SQL,并在准备部署时将它们应用到生产服务器。

南方可能有这种事吗? (我也很好奇其他人在使用 Django 时会做什么来让你的开发数据库在生产中发生变化)

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)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

梦里的微风 2024-11-11 18:53:44

您至少可以检查通过执行 manage.py migrate --db-dry-run --verbosity=2 生成的 sql。这不会对数据库执行任何操作,并且会显示所有 sql。不过我还是会做备份,安全总比后悔好。

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.

小情绪 2024-11-11 18:53:44
 python manage.py sqlmigrate <app_label> <migration_name>
 python manage.py sqlmigrate <app_label> <migration_name>
温柔少女心 2024-11-11 18:53:44

您可以尝试使用管理命令在 db.connection.queries 中记录 SQL 查询,该命令使用空运行选项调用迁移:


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 将所有内容都通过应该可以工作的常用数据库接口进行。当它查询历史表时,会有一些额外的选择。

您可以将其放入应用程序内的 management/commands/print_migration_sql.py 中,然后运行它:


python manage.py print_migration_sql

它可能可以轻松扩展为仅针对特定应用程序等运行它

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

庆幸我还是我 2024-11-11 18:53:44

当我需要查看 South 生成的用于调试或验证的 SQL 时,我只需将以下日志记录设置添加到我的 local_settings.LOGGING.loggers 中:

    '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 的查询running 来决定要运行哪些迁移:

[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 通常足以清楚地了解正在发生的情况。

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.

方圜几里 2024-11-11 18:53:44

我要么按照 Lutger 的建议进行操作(也许编写一个日志解析器来删除只是 SQL),或者在测试数据库上启用日志记录的情况下针对测试数据库运行迁移。

当然,如果您可以针对测试数据库运行它,那么您距离验证迁移仅几步之遥。如果通过,则针对生产再次运行它。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文