对于我的生活，我无法找到有关如何使用Google App Engine和CloudSQL处理迁移的文档。我正在使用Go运行时。
显然，应用程序的架构会随着时间的推移而变化和发展，并且需要运行迁移。目前我手动运行迁移。这不可扩展。
有没有人有解决方案？
我看到了一些具体的挑战：
我可以使用VersionID获取当前app.yaml部署版本的版本。但是，如何检查此版本是否发生了迁移？我必须在db表中保留一个版本号，并在init()函数中检查它吗？
但是，当您上传新版本的应用时，使用新架构GAE会慢慢地migrate your traffic，这意味着一旦新版本中的第一个init()实例运行，迁移完成后，旧版本的流量将在这些数据库事务中失败。
我可以通过对API进行版本控制来缓解上述问题。但这限制了迁移策略，例如丢弃表格等。
最后，据我所知，我对此没有documentation感到失望。
答案 0 :(得分：2)
我不得不同意Robert的看法，虽然这是一个具有挑战性的情况，但它与CloudSQL几乎没什么关系。几乎任何需要使用不同的SQL模式迁移两个版本的应用程序的情况都会产生这种情况。
你基本上有两个选择
使所有更改至少暂时向后兼容。这可能涉及应用程序的中间版本，可以优雅地处理模式的任一版本。
您所描述的app / API版本，将给定版本与给定架构相关联并使用不同的数据库，这可能需要在两个数据库之间复制数据，这可能会使用比您更多的存储空间。 ; d喜欢。
向后兼容的方法通常是最好的，尽管你会得到一些丑陋的代码来处理不同的模式。但通常可以这样做。
您在询问如何获取给定版本是否具有给定迁移，但请记住迁移是数据库的属性，版本是应用程序的属性。所以问题实际上只是版本所涉及的数据库以及该数据库的模式。你对＃34;版本的想法＆＃34;数据库中的迁移数实际上是非常合理的，许多ORM都具有某种功能。
这个问题存在的事实是为什么在第一次对应用程序进行原型设计时允许更灵活的数据建模方法（允许更多的NULL，不使用外键，或者只使用像Datastore这样的NoSQL方法），一旦您对数据模型更有信心，就可以实现更多的数据完整性。
最后，我处理了Google云端文档，如果您感到失望我们不能更清楚地解决这个问题，我很抱歉，但希望您理解它是一般数据库的观点操作问题而不是Google Cloud或App Engine特有的问题。如果您确实想出一个您喜欢的解决方案，那么您应该考虑一下博客，我们很乐意帮助推广您的解决方案！