オーバーライドを実行するときにフィールドと条件を検証する方法

Question

中央サーバーと、d1、d2、d3、d4、d5 などのいくつかの地域サーバーがあります。

コピーするテーブルがいくつかあります。話を簡単にするために、d1、d2、d3、d4、d5、および c に存在し、これらすべてのサーバーで同じ構造を持つ tblFoo というテーブルがあると仮定します。ルールは簡単です:

• レコードがサーバー d に存在する場合、そのレコードはサーバー c にも存在し、各フィールドの値はまったく同じです
• レコードが d サーバー (例: d1) に存在する場合、そのレコードは他の d サーバー (d2、d3、d4、または d5) には存在しません。

目標は、d サーバー上の tblFoo に変更 (挿入、更新、削除) が行われた場合、c サーバーでも即座に変更されるようにすることです。これは挿入操作に最適です (pkFooID である ID には定義により auto_increment 属性があるため)。これは更新および削除操作にも機能しますが、これらの操作にはいくつかの懸念があります。コードは次のとおりです (簡易バージョン):

リーリー

問題は: d1でupdateまたはdeleteステートメントを実行し、その条件が他のリージョンサーバー(d2、d3、d4、d5)で満たされる場合、正しく実行されます。 d1 では update ステートメントと delete ステートメントを実行しますが、同じステートメントが d1 で実行されると、c サーバーの他のリージョンのレコードを誤って更新/削除する可能性があります。

この問題を解決するには、ステートメントを検証し、次の条件のいずれかが満たされない場合に例外をスローすることをお勧めします。

条件は=またはIN
• です
フィールドは [pk|fk]*ID、つまり外部キーまたは主キーです

レプリケーション動作のないテーブルは通常どおり実行されます。上記の制限は、この例の tblFoo など、レプリケーション動作のあるテーブルにのみ適用されます。

＃＃＃質問＃＃＃

主キーまたは外部キーのみを検索し、= または IN 演算子のみを使用できるように、リライト実行で更新/削除クエリを検証するにはどうすればよいですか?

Answer 1

これが私が問題を解決した方法です。

コピー動作を持つモデルは次の検証を実行します:

リーリー

Query クラスには、必要な検証をトリガーする isReplicate メソッドがあり、条件が確実に満たされるように where メソッドがオーバーライドされています。正しく検証されました ：

リーリー