Jak rozwiązać konflikty przy ciągłej replikacji

Jestem nowym użytkownikiem zarówno CouchDB, jak i PouchDB i używam go do tworzenia systemu zarządzania kontaktami, który synchronizuje się z urządzeniami mobilnymi i stacjonarnymi i może być używany w trybie offline. Widzę, że używanie PouchDB jest nieskończenie łatwiejsze niż pisanie backendu PHP / MySQL.

Korzystam z niego z powodzeniem, a kiedy wprowadzam sprzeczne zmiany na urządzeniach offline, CouchDB używa algorytmu do arbitralnego wyboru zwycięzcy, a następnie poprawnie wypycha go do wszystkich urządzeń.

Chciałbym zaimplementować niestandardowy algorytm do łączenia sprzecznych rekordów. Oto algorytm, którego chciałbym użyć:

Jeśli rekord zostanie usunięty na jednym kliencie i tylko zaktualizowany na innym, zaktualizowana wersja wygrywa, chyba że obaj klienci zgodzą się na usunięcie.Rekord z najnowszym „zmodyfikowanym” znacznikiem czasu staje się rekordem głównym, a starszy rekord staje się drugorzędnym.Wszystkie pola, które istnieją tylko w drugorzędnym (lub są puste w wzorcu), są przenoszone do wzorca.Wersja główna jest zapisywana, a pomocnicza jest usuwana.

Przewodnik CouchDB ma coś dobregowyjaśnienie, ale nie mam pojęcia, jak zaimplementować go za pomocą API PouchDB podczas ciągłej replikacji. WedługPouchDB API, w opcjach replikacji znajduje się detektor „onChange”, ale nie rozumiem, jak go używać do przechwytywania konfliktów.

Jeśli ktoś mógłby napisać krótki samouczek zawierający przykładowy kod, ja i jestem pewien, że wielu innych użytkowników PouchDB by to doceniło!

questionAnswers(1)

yourAnswerToTheQuestion