Staré české přísloví říká: „Nejhorší je srážka s blbcem“. My se nyní nebudeme pokoušet o takovýto akt, ale bude řešit jisté srážky. Konkrétně tedy kolize vzniknuvší během naší připravené synchronizace. Pokud jste zkoušeli příklady v předchozích dílech, určitě jste si uvědomili, že konflikty mohou vzniknout, ale kód se jimi vůbec nezabývá. Nyní přišel čas na jejich ošetření.
reklama
Staré české přísloví říká: „Nejhorší je srážka s blbcem“. My se nyní nebudeme pokoušet o takovýto akt, ale bude řešit jisté srážky. Konkrétně tedy kolize vzniknuvší během naší připravené synchronizace. Pokud jste zkoušeli příklady v předchozích dílech, určitě jste si uvědomili, že konflikty mohou vzniknout, ale kód se jimi vůbec nezabývá. Nyní přišel čas na jejich ošetření.
Zkráceně řečeno, konflikt vznikne, pokud se dva nebo více participujících stran pokusí „upravit“ stejná data. Typickým příkladem je změna jednoho řádku na dvou zařízeních. Konflikt ale může vzniknout i při vkládání apod. MSF rozlišuje čtyři typy kolizí plus dvě obecné:
- ClientUpdateServerUpdate: Klasický konflikt, který vzniká při změně stejného řádku dvěma (a více) stranami.
- ClientInsertServerInsert: Zjednodušeně řečeno se jedná o kolizi primárních klíčů. Vznikne při vložení záznamů se stejným PK.
- ClientUpdateServerDelete: Klient řádek editoval, ale na serveru byl smazán.
- ClientDeleteServerUpdate: Stejné jako výše, pouze prohozené role.
Obecné:
Abychom mohli konflikty detekovat a řešit, obsahuje MSF resp. server a client provider událost ApplyChangeFailedEvent. Třebaže by se mohlo zdát, že událost u obou je zbytečná, je třeba si uvědomit, že kolize z pohledu klienta jsou jiné než z pohledu serveru. Operace na obou stranách jsou však stejné. V události ApplyChangeFailedEvent můžeme určit, jak naložit s konfliktem. Máme na výběr tři možnosti:
- Continue: Ignorovat konflikt a pokračovat v synchronizaci.
- RetryApplyingRow: Znovu aplikovat daný řádek. Beze změny řádku bude událost vyvolána znova. Vhodné pokud dáváme uživateli možnost změnit řádek.
- RetryWithForceWrite: Daný řádek bude znovu aplikován a přepíší se ostatní změny. SqlCeClientSyncProvider, který my používáme, má přímou podporu pro tuto možnost. Využívá se pro ni parametr @sync_force_write, podle něhož můžeme v našich příkazech/procedurách rozhodnout, jak „agresivně“ pokračovat.
Protože jsem již zmínil SqlCeClientSyncProvider a jeho přímou podporu, zmíním též jeho property ConflictResolver. Díky této vlastnosti můžete pro každý konflikt říci, zdali klient nebo server „vyhraje“ či bude vyvolána událost (implicitní možnost). Toto nastavení samozřejmě není povinné, ale může ulehčit řešení konfliktů na klientovi.
Abychom pochopili, kdy se která událost vychovává, je třeba si uvědomit, kde se chyba vyskytla. Když klient uploaduje řádky na server, vznikají konflikty na serveru (i když díky klientovi). Proto je vyvolána událost na DbServerSyncProvideru. Naproti tomu událost na SqlCeClientSyncProvideru je vyvolána při download fázi, kdy jsou řádky ze serveru aplikovány na klienta. S touto znalostí je třeba navrhovat řešení kolizí a správně se rozhodnout u obou událostí (dodržet správný „směr“). Důležité je poznamenat, že pokud není konflikt ošetřen během synchronizace, do další obrátky se již nedostane a je třeba provést např. dummy update, aby byl znovu zařazen.
Vrátíme-li se zpět k události ApplyChangeFailedEvent, a podíváme-li se na parametr typu ApplyChangeFailedEventArgs, najdeme kromě vlastnosti Action, která nám ovlivňuje chování i několik dalších významných vlastností. Property Conflict obsahuje, mimo nakousnutého výčtu ConflictType, i tabulku ClientChange resp. ServerChange. Tyto property, typu DataTable, obsahují hodnoty sloupců konfliktního řádku na klientovi resp. na serveru. Můžeme je tak lehce využít pro zobrazení dialogu uživateli, který může rozhodnout jak pokračovat.
Přestože se může zdát, že řešení konfliktů není problém, opak je pravdou. Promyslet všechny možnosti a správně na ně reagovat není nic lehkého. Proto je vhodné aplikaci navrhovat tak, aby konfliktů vznikalo minimum a maximálně se jim předcházelo..