GAE CloudSQL的最佳迁移策略是什么？

Question

在我的一生中，我找不到关于如何使用Google和CloudSQL.I处理迁移的文档。

显然，应用程序的模式将随着时间的推移而改变和发展，迁移将需要运行。目前，我手工操作迁移。这是不可伸缩的。

有谁有解决办法吗？

我看到一些具体的挑战：

• 我可以使用app.yaml获得当前VersionID部署版本的版本。但是，如何检查此版本是否发生了迁移？我必须在db表中保留版本号，并在init()函数中对照它进行检查？
• 但是，当您上传应用程序的新版本时，新模式GAE将缓慢地迁移您的流量，这意味着一旦新版本中的init()第一个实例运行，迁移完成，到旧版本的通信将在这些db事务中失败。
• 通过对API进行版本化，我可以在一定程度上缓解上述问题。但这限制了迁移策略，如删除表等。

最后，我感到失望的是，据我所知，在这方面没有文档。

Answer 1

我必须同意罗伯特的观点，虽然这是一个具有挑战性的情况，但与CloudSQL没有什么关系。几乎所有您需要用不同SQL模式迁移两个版本的应用程序的情况都会造成这种情况。

你基本上有两个选择

• 使您的所有更改至少暂时向后兼容。这可能涉及到您的应用程序的中间版本，它可以优雅地处理模式的任何版本。
• 如您所描述的应用程序/API版本，将给定版本与给定模式相关联，并使用不同的数据库，这可能需要在两个数据库之间复制数据，这可能使用比您希望的更多的存储空间。

向后兼容的方法通常是最好的，尽管您有一些丑陋的代码来处理不同的模式。但通常是可以做到的。

您在询问如何获得给定版本是否有给定迁移，但请记住迁移是数据库的属性，版本是应用程序的属性。因此，问题在于版本所讨论的是哪个数据库，以及该数据库的模式是什么。您对于数据库中迁移的“版本”编号的想法实际上是相当合理的，而且许多ORMs在这方面都有一些特性。

这个问题存在的事实是，为什么在第一次创建应用程序时使用更灵活的数据建模方法会更好(允许更多的NULL，不使用外键，或者只使用像Datastore这样的NoSQL方法)，并且一旦您对数据模型有了更多的信心，就会实现更多的数据完整性。

最后，我研究Google文档，如果您对我们没有更清楚地解决这个问题感到失望的话，我很抱歉，但是希望您理解这是一个一般性的数据库操作问题，而不是专门针对Google或App的问题。如果你想出了一个你喜欢的解决方案，你应该考虑写博客，我们很乐意帮助你推广你的解决方案！