問題タブ [schema-migration]

Flywayを使用してセットアップされた既存のデータベースがあり、このデータベースを RDBMS の最新バージョン (例: Postgres 9.2->9.3) に移行したいと考えています。

データベース ベンダーが API で何かを変更し、既に実行した移行の 1 つでエラーが発生した場合、同じ移行スクリプトを使用してバージョン 9.3 で新しい開発データベースをセットアップすることはできません。失敗した移行スクリプトを修正する必要があります。

その後、本番データベースを postgres 9.3 にアップグレードし、新しい移行を実行しようとすると、変更された移行スクリプトのチェックサムが一致しないため、既存の本番データベースでは移行できません。

この状況に対処する最善の方法は何ですか? 私が現在見ている唯一の方法は、運用データベースの schema_version テーブルのチェックサム値を手動で変更することです。

チームメイトと私は南を少しの間使用しており、問題はほとんどありません。追加したモデル フィールドを South が認識しないという問題が発生しました。

私が走るとき

「何も変わっていないようだ」というメッセージが何度も出てきます。

その他のランダムな詳細:
South==0.8.2
データベース テーブルを確認しましたが、実際には列がありません。

更新 #1: 独自の移行ファイルを作成して追加したところ、機能しました。スキーママイグレーションを使用してもうまくいかなかった理由を理解しようとしているだけなので、手動でやり続ける必要はありません..

更新 #2: 使用しているフィールド タイプに関係があるのではないかと感じています..? 私はcharfieldを追加しようとしましたが、南はうまくいきましたが、URLフィールドに関してはまったく認識されません...

回答: 何が問題なのかわかりました。チームメイトは、メソッド名でもある変数名を使用していました。十分な担当者がいないため、まだ自分の質問に答えることができませんが、できるときに答えます.

私は南にかなり新しいです。私は友人のプロジェクトに取り組んでおり、彼はすでにいくつかの移行を行っているようです。

モデルがあり、そのモデルに ManyToMany フィールドを追加しようとしています。owned_geofencesこれは、追加しようとしているフィールドであるクラスです。

アプリの名前は「プロファイル」です。最初に私はこれをしました：

うまくいったようです。それから私はこれをしました：

わかった。今、それは正しく機能しているはずですか？

まあ、それはうまくいったようです。私はいくつかのテストを実行しました..

その上で、好奇心から私は走った：

これらが同期されないのはなぜですか? 私は何かを台無しにしていると思ったので、上記のアドバイスを受けて実行しました：

誰かがここで何が起こっているのかを明らかにしてもらえますか?

「マルチスキーマ」戦略を使用するマルチテナント SaaS アプリケーションがあります。つまり、すべての顧客が同じデータベース インスタンスに専用のスキーマを持っています。MS SQL Server をデータベースとして使用し、SQL Server の「ユーザー」の「デフォルト スキーマ」設定を介してスキーマを切り替えます。たとえば、顧客 A、B、C は SQL Server で次のように構成されています。

• 顧客 A:user_Aデフォルトのスキーマを使用schema_A
• 顧客 B:user_Bデフォルトのスキーマを使用schema_B
• 顧客 C:user_Cデフォルトのスキーマでschema_C... など。

このアプリケーションでは、すべてのクエリの前に次の SQL を実行して、接続に SQL Server "ユーザー" を設定することにより、DataSource 接続を各顧客の正しいスキーマを指すように切り替えます。

これは、グローバルな方法でスキーマ バージョンの状態を管理するために Flyway を使用しようとするときに、いくつかの問題を引き起こします。flyway のスキーマ サポートはスキーマ名のリストのみを受け取るため、これは MS SQL Server では機能しません。Flyway は、DataSource 構成で提供されたユーザーのデフォルト スキーマで移行を実行します。SQL Server の場合、「ユーザー」は顧客/スキーマごとに異なる必要があります。

理想的には、FlywayCallback.beforeEachSchemaMigrate(Connection)スキーマごとの各移行の前に「Execute as User」ステートメントを実行することで、スキーマごとに目的のユーザー コンテキストを設定できるようなコールバックが必要です。なぜそのフックがないのかわからない？

schema_versionフライウェイのもう1つの欠点は、テーブルを保持するスキーマとして、スキーマのリストの最初のスキーマを使用するという規則です。これは、SQL Server ベースのマルチテナント環境では望ましくありません。schema_versionテーブルを含むスキーマが実際の Customer スキーマでもあるとは想定できないためです。私たちのような SaaS アプリケーションでは、テナント/顧客ごとのスキーマがその場で作成/破棄されることに注意してください。ユーザーがサインアップすると、プロビジョニング プロセスの一部で、いくつかの規則に基づいて新しいスキーマが作成されます。したがって、スキーマのリストは動的です。

schema_version理想的には、そのスキーマで移行を実行しようとせずに、特定のスキーマを使用してテーブルを作成するように Flyway に指示できます。通常、これはdboスキーマ (SQL Server の既定のスキーマ) です。dbo スキーマを使用して、すべてのテナントにわたって本質的にグローバルなテーブルを保持します。schema_version はグローバル テーブルと見なされます。

したがって、移行が成功すると、データベースは次のようになります。

上記のスキーマはすべて同じ「状態」にあり、dbo.schema_versionテーブルによって指示および制御されます。

これは現在可能ですか？

私はこのチュートリアルに従い、PostgreSQL FTS 機能を Django (私は 1.8.1 を使用しています) プロジェクトのテーブルの 1 つに追加しました。

基本的に、アプリfts_documentのテーブルに追加のフィールドがあります。my_tablemy_app

各マシンの PostgreSQL シェルでコマンドを手動でコピー アンド ペーストすることなく、データベースを最新の状態に保ちたいと考えています。チュートリアルとは異なり、South の部分は実装しませんでした。これは、South が現在の実装と競合し、Djangoにはこれらの移行を行うためのネイティブな方法がないこともわかったためです。

サンプル コードが見つからなかったため、行き詰まっており、助けが必要です。チュートリアルのように正確な構造と手順に従ったため、サンプルコードは投稿しません。