GAE CloudSQLの最適な移行戦略は何ですか

Question

Google App EngineとCloudSQLを使用して移行を処理する方法については、私の生活の中でドキュメントを見つけることはできません。Goランタイムを使用しています。

明らかに、アプリケーションのスキーマは時間が経つにつれて変化し、進化し、移行を実行する必要があります。現在、私は手動で移行を実行しています。これはスケーラブルではありません。

ソリューションをお持ちの方はいらっしゃいますか？

私はいくつかの具体的な課題を参照してください。

• 私はVersionIDを使用して、現在のapp.yamlデプロイされたバージョンのバージョンを取得することができます。ただし、このバージョンで移行が行われたかどうかを確認するにはどうすればよいですか？私はdbテーブルにバージョン番号を保持し、それに対してinit()機能でチェックする必要がありますか？あなたはGAEはゆっくりmigrate your trafficあなたの新しいバージョンを実行中init()の最初のインスタンスたら意味し、移行が完了すると、古いバージョンの意志へのトラフィック新しいスキーマで、アプリの新バージョンをアップロードしかし

• 、それらのdbトランザクションで失敗します。

• 私のAPIをバージョン管理することで上記の問題を多少緩和することができました。しかし、これは最後に

、テーブルをドロップするように移行戦略、などを制限し、私はdocumentationは、私の知る限り、この上ありません失望します。

Answer 1

これは難しい状況ですが、CloudSQLとはほとんど関係がありません。異なるSQLスキーマを持つ2つのバージョンのアプリケーションを移行する必要がある場合は、この状況が発生します。

あなたは基本的に2つのオプション

• を持っているが、少なくとも一時的にすべての変更が後方互換性を確認します。これには、いずれかのバージョンのスキーマを正常に処理できるアプリケーションの中間バージョンが必要です。

• バージョンを指定したスキーマに関連付けて、別のデータベースを使用します。これにより、2つのデータベース間でデータをコピーする必要があります。 。

異なるスキーマを処理するためのいくつかの醜いコードを取得しても、後方互換性のあるアプローチが最適です。しかし、それは通常行うことができます。

特定のバージョンに特定の移行があるかどうかを確認しますが、移行はデータベースの属性であり、バージョンはアプリケーションの属性であることに注意してください。だから問題は、実際にはバージョンが話しているデータベースとそのデータベースのスキーマだけです。データベース内の移行用の「バージョン」番号についてのあなたの考えは、実際には非常に妥当であり、多くのORMには、ある種の機能があります。

この問題が存在するという事実は、最初にアプリケーションのプロトタイプを作成したとき（より多くのNULLを許可する、外部キーを使用しない、またはDatastoreのようなNoSQLのアプローチを使用する）データ・モデルの信頼性が向上すれば、より多くのデータ整合性を実装できます。

最後に、私はGoogle Cloudのドキュメントを作成していますが、残念ながらご迷惑をおかけして申し訳ございませんが、より具体的に対処することはできません。 Google CloudまたはApp Engine。あなたが好きなソリューションを思いつくなら、それについてブログをすることを検討すべきです。私たちはあなたのソリューションを宣伝するのを手伝ってくれるでしょう！