Javers比較列表

我試圖通過解釋容器更改（v1.6.0）將兩個實體列表上的差異轉換爲更易讀的格式。Javers比較列表

如果我有實體的列表（listBefore）：

entity1 
    entity2 
    entity3 
    entity4

，我重新排序列表（listAfter）

entity1 
    entity4 
    entity2 
    entity3

使用比較這些列表的結果

Javers.compareCollections(listBefore, listAfter, Entity.class)

是：

containerChanges:[(3).removed:'entity4', (1).added:'entity4']

由此我可以推斷：entity4從指數3移到索引1

如果我重複同樣的比較，這次加入新的項目到第二個列表：

entity1 
    entity4 
    entity2 
    entity3 
    entity5

的比較的結果是：

containerChanges:[(3).'entity4'>>'entity5', (1).added:'entity4']

這似乎錯過了'entity5'被添加到索引（4）（即不是3）和'entity4'像前面的例子一樣移動。

更新：我在上面的例子中使用了Levenshtein比較器。

任何澄清，將不勝感激。

2016-05-23 stacktrace

簡單的算法，默認情況下使用，主要是因爲它的速度。 Levenshtein更聰明，但對於非常大的列表可能會很慢。來自JaVers文檔：

SIMPLE算法生成移位元素的更改（如果元素在列表中間插入或移除）。相反，Levenshtein算法即使在元素被移位的情況下也會計算出短而清晰的變化列表。它不關心換位元素的索引更改。

我的建議，試試Levenshtein距離算法。

2016-05-24 07:24:53

對不起，我應該澄清 - 我正在使用Levenshtein距離算法。這就是爲什麼在第一個例子中它忽略了entity2和entity3的轉變。當我向列表添加一個新元素（上面的第二個例子）時，結果看起來不正確。 – stacktrace

目前，我使用兩個列表中時間最長的子序列進行自定義比較。任何不屬於子序列（或添加或刪除）的元素都被認爲是從一個索引到另一個索引的移動。問題在於框架不支持「重新排序」更改類型，所以我需要在常規更改處理之外處理此問題。 – stacktrace

在JaVers列表比較算法中沒有移動的概念。在移動之後，會有兩個更改報告：ValueAdded和ValueRemoved，就像您提到的一樣。 –

回答