Unification Algorithm の解説#
この場合の Unification Algorithm を解説する。
graph_unify_loop_0 (1,2,3,graph も同様)#
Fig. 48 graph_unify_loop_0#
実は、今回は初期の graph が最終状態となっている。なぜなら、従来の Algorithm では “leader_id: 2” が “leader_id: 1” に置き換わってしまう (マージされてしまう) はずだが、do_not_merge_key: で設定されている member_id ではマージされないようになっているので、これ以上変化が起きないのである。
canonical_id について#
canonical_id の生成と割り当て#
今回のケースでは、4種類の canonical_id が生成されることになる。
Fig. 49 canonical_id の生成と割り当て#
従来と異なるのは、収束状態に関わらず、”follower: a@ex.com” が、2つの leader である “member_id: 1” と “member_id: 2” を指している状態であることである。
実際、lookup テーブルにおいても a@ex.com におけるレコードが2行あることになる。
id |
canonical_id |
|---|---|
1 |
4ydklKlyPnfa |
2 |
XNKI3XAY1Hja |
3 |
xqaWYjT4GR3a |
a@ex.com |
4ydklKlyPnfa |
a@ex.com |
XNKI3XAY1Hja |
b@ex.com |
xqaWYjT4GR3a |
c@ex.com |
NEKDReELMAxH |
これは、アルゴリズムの収束判定方法の1つである、「全ての follower がただ1つの leader だけを指している」状態にならずに収束していることを意味する。ただ、もう1つの方法である「WF Logs の +report_diff タスクの出力を確認する」方法は有効である。