Uitdoofsynchronisatie

Synchroniseren. Hoe moeilijk kan het zijn? Je neemt potlood en papier en tekent snel wat schemaatjes met een aantal scenario’s die zich mogelijk kunnen voordoen bij het synchroniseren. Deze blogpost is het verhaal waarin ik op zoek ga naar de ideale manier waarop verschillende mobiele devices steeds over dezelfde informatie (vakken) beschikken én die informatie kunnen aanpassen. Simpel, toch?

  1. Data downloaden en gewoon alles overschrijven.
    Toegegeven, dit is nogal drastisch. Maar hé, het werkt. We vergeten gemakkelijkheidshalve dan wel dat ALLE data downloaden zelden nodig is, laat staan alles overschrijven…
    Eigenlijk had deze eerste stap meer als doel vertrouwd te raken met de API van de rest-server. Data versleuteld downloaden, aanmelden met Digest access authentication, gegevens versturen naar de rest-server etc.



    Your browser does not support the canvas element.Stap 1: Data downloaden en gewoon alles overschrijven.

    Stap 1: Data downloaden en gewoon alles overschrijven.

  2. Kijk welke vakken niet online staan (op basis van ID) en download enkel die vakken.
    Stap twee, we voegen basislogica toe aan het downloadproces.
    We downloaden niet meer klakkeloos alle vakken, maar enkel de vakken die we nog niet hebben. Om dat te kunnen doen, maken we twee lijstjes met alle vak-ID’s online en alle vak-ID’s offline. Daarna vergelijken we beide lijstjes en weten we welk vak ontbreekt en waar het ontbreekt.
    In het geval van het prentje hieronder ontbreekt online het vak met ID 125. Dat vak uploaden we dus naar de online database zodat we daar ook vak 125 hebben.

    Stap 2: Vergelijk ID's van vakken online met vakken offline

    Stap 2: Vergelijk ID’s van vakken online met vakken offline

  3. Kijk welke vakken offline staan, kijk welke vakken online staan en synchroniseer deze.
    Oeps! Probleem. Een ID-nummer is immers niet representatief voor een vak. Als ik offline een nieuw vak aanmaak dan zal dat nieuwe vak een nieuw ID-nummer krijgen. De kans is groot dat er ondertussen online ook een vak is aangemaakt met datzelfde ID. Hoewel het vak met ID-nummer 195 dus zowel offline als online aanwezig is, gaat het wel degelijk over een ander vak. Afgaan op ID-nummers gaat dus niet. Een vak-ID is dus enkel representatief voor één vak binnen dezelfde database. Als we met verschillende databases werken, in dit geval online en offline, dan kan een vak-ID twee keer voorkomen en toch naar een ander vak verwijzen.Het probleem ligt bij de automatische nummering in de database. Nieuwe inhoud krijgt een nummer mee dat net 1 eenheid groter is dan de vorige inzending. Als een device geen verbinding heeft met het internet en de laatste inzending 124 was dan zal de volgende inzending 125 zijn. Ook als er ondertussen door andere mensen 30 nieuwe vakken ingediend zijn en het eigenlijke ID-nummer dus 155 had moeten zijn.

    ID is hetzelfde, titel is anders

    ID is hetzelfde, titel is anders

    Een mogelijk oplossing bestaat eruit de data zelf te gaan vergelijken. Omdat het over (potentieel) gevoelige data gaat, leek het mij veiliger om niet de data zelf maar de md5-hashes van de data te gaan vergelijken. Dat werkte.
    Als we met verschillende data zitten en het ID-nummer is hetzelfde, nemen we de meest recente wijziging.

    Vergelijken van vaktitels dmv md5-hashes

    Vergelijken van vaktitels dmv md5-hashes

    Oh ja?
    Want als we zowel vak 125 online als het vak 125 offline willen behouden, dan zal dat niet gaan. We zouden 1 van beide immers overschrijven met het vak dat het laatst werd aangemaakt.

    Of stel: Jan Janssens synchroniseert in februari zijn data en vertrekt een maand op vakantie. In maart vinden er verschillende grote wijzigingen plaats in de online database. In april keert Jan Janssens terug, kan niet synchroniseren, maar maakt toch een aanpassing aan de data en wil dan zijn veranderingen online opslaan.

    Probleem! Hoewel de data van Jan Janssens wel over de recentste data beschikt, is het zeker niet zijn data die we online willen hebben.

    Data samenvoegen (mergen) met de reeds bestaande data, is door de aard van de data niet mogelijk. Oeps.

    Volgende idee: we bewaren beide vakken, wetende dat dat niet ideaal is.

  4. Bewaar beide vakken.
    Bewaar beide vakken. Ok. Maar hoe? Ze hebben hetzelfde ID. Moeten we dan nog een tabel aanmaken die het online ID koppelt aan het offline ID? Moeten we het vak-ID aanpassen? Maar hoe? En wat wanneer er al een vak bestaat met dat nieuwe ID? Gaan we bij elke synchronisatie dan op zoek gaan naar alle vrije ID’s en dat vak dan dat nieuwe ID geven? Op die manier zou het kunnen dat een vak tijdens zijn bestaan verschillende keren van ID verandert. Ook niet echt ideaal denk ik dan.

  5. Hou een logboek bij met veranderingen.
    Vanaf hier is het pure improvisatie, louter gebaseerd op een denkoefening en (nog) niet geprogrammeerd. Informatie onder voorbehoud dus.In onze database maken we een nieuwe tabel aan waarin we alle veranderingen opslaan.
    Als er bij die veranderingen bijvoorbeeld een vak aangemaakt is en online heeft er nooit zo’n actie plaatsgevonden dan weten we, ongeacht het vak-ID, dat er online een nieuw vak aangemaakt moet worden. Omgekeerd werkt dat ook uiteraard, als er online een vak is verwijderd en dat vak is nog wel offline aanwezig dan kunnen we dat vak verwijderen. Hoe weten we nu welk vak verwijderd moet worden als we vak-ID’s niet mogen vertrouwen?
    We slaan bij elke verandering een md5-hash van de data op, we vergelijken dan de md5-hash van die online data met de md5-hash van onze data offline.Zo’n tabel met alle aanpassingen wordt uiteraard in no-time gigantisch groot. We slaan immers alle data dubbel op.
    Op zich geen probleem, maar we hoeven die data niet voor eeuwig te bewaren.

  6. Vergeet veranderingen
    Offline is dat redelijk eenvoudig. Als het device verbinding gemaakt heeft met de server en alle gegevens gesynchroniseerd zijn, dan kan het volledige lokale logboek met de veranderingen verwijderd worden. Online is het iets ingewikkelder. Omdat we niet weten hoeveel devices er zijn en sommige devices maar 2 of 3 keer synchroniseren en daarna nooit meer, kunnen we onmogelijk alle veranderingen blijven bijhouden.

Deze manier van data synchroniseren is het resultaat van een persoonlijke denkoefening en dus verre van perfect. Moesten er slimme mensen op de wereld zijn die voor dit probleem een betere oplossing hebben,  lees ik hun oplossing graag in de commentaren hieronder.

Note: In dit voorbeeld gebruik ik als voorbeeld md5 om data te encrypteren. Ik ben mij er van bewust dat er andere en betere manieren bestaan om data one-way te encrypteren. Mocht je dus echt gevoelige data willen opslaan doe je er goed aan jezelf hierover eerst te informeren. ;-)

Leave a reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.