Django - South - 有没有办法查看它运行的 SQL?
这就是我想做的。
在具有开发数据库的开发服务器上开发 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
您至少可以检查通过执行
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.您可以尝试使用管理命令在 db.connection.queries 中记录 SQL 查询,该命令使用空运行选项调用迁移:
假设 South 将所有内容都通过应该可以工作的常用数据库接口进行。当它查询历史表时,会有一些额外的选择。
您可以将其放入应用程序内的
management/commands/print_migration_sql.py
中,然后运行它:它可能可以轻松扩展为仅针对特定应用程序等运行它
You could try logging the SQL queries in db.connection.queries, using a management command that calls the migrate with a dry-run option:
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:It could probably be easily extended to run this only for specific apps etc
当我需要查看 South 生成的用于调试或验证的 SQL 时,我只需将以下日志记录设置添加到我的 local_settings.LOGGING.loggers 中:
这是 South 日志记录设置的完整示例:
这将输出所有内容,包括 South 的查询running 来决定要运行哪些迁移:
将详细程度设置为 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:
This is a complete example of the logging setting for South:
This will output everything including the query that South runs to decide what migrations to run:
That and setting verbosity to 2 or 3 is usually more than enough to get a clear picture of what's going on.
我要么按照 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.