如何在breeze.sharp或breeze.js中實現衝突解決,以及它如何與新發布的Azure「AsyncTable」衝突處理進行比較?用微風解決衝突
這種情況是這樣的:一個實體(例如Person)被保存在微風緩存中,從之前的服務器獲取數據(將數據保存在緩存中的原因是爲了讓用戶能夠使用應用程序,而移動設備與互聯網斷開連接)。當移動設備處於離線狀態時,用戶在人員上編輯一些細節(例如編輯姓氏)。與此同時,其他人編輯同一個人的姓,併成功保存到Azure(或中央MS SQL)數據庫。然後,移動設備再次聯機,並將其更新(已存儲在本地緩存中直到現在)發送到服務器。
我的問題是,怎麼能/應該用微風來開啓選擇這兩個衝突更新之間的「勝利者」的可能性?決定勝利者的機制在這裏不是問題。我只想知道如何纔能有機會做出這個決定 - 然後如何讓贏家的姓氏版本在失敗者身上(即移動設備或服務器數據庫)持續存在。
最近我設法得到這個答案是在「保存更改」頁面上的微風文檔中,它說:「此頁面尚未準備好發佈,它將涵蓋:...併發性和DataProperty .concurrencyMode」。
我不確定這個需求是否可以通過樂觀併發或者更接近Azure的方式來實現(實體上的版本字段和其他未知的魔法衝突解決方案和同步邏輯)將需要使這項工作輕而易舉?
'DataProperty.concurrencyMode'只是Breeze識別用於樂觀併發的屬性的方式;通常是一個'rowversion'屬性。 Breeze會在實體更新時自動增加這些屬性。 –
您是否在尋找自動化的衝突解決方案(應用程序或服務器選擇贏家),還是手動解決方案(用戶是選擇的)? –
您好史蒂夫,我現在意識到併發只能處理同樣的第二類情況,而衝突解決則是需要更長的時間範圍(例如,當設備脫機時更新字段可能需要數小時或數天才能到達設備再次在線,所以併發功能對我來說不會有好處)。將會有定製邏輯來決定哪個應該是贏家,並且可以在客戶端或服務器上進行。不需要UI交互。是否可以在服務器端重寫SaveChanges方法?如果有一種經過驗證的方法,這將是很好的選擇。 – user2935274