Synchronizacja projektu

Projekt Mapit to GeoPackage: jeden plik z warstwami, formularzami i wszystkim, co do nich zebrano. Kiedy projekt trafia do chmury, plik pozostaje plikiem, a kopia na serwerze jest tą, z którą uzgadniają się wszystkie urządzenia. Nic nie zostaje rozbite na bazę danych, z której dane da się odczytać wyłącznie za naszym pośrednictwem. Dlatego odpowiedzią na pytanie „czy możemy dostać nasze dane” jest pobranie pliku, a nie zgłoszenie do pomocy technicznej.

To, co podróżuje, nie jest plikiem. Telefon, który już ma projekt, wysyła zmienione wiersze i odbiera wiersze zmienione przez innych, więc pierwsza synchronizacja przenosi cały projekt, a każda kolejna już tylko różnice. Dlatego druga i dwusetna synchronizacja są równie małe i dlatego zespół przy słabym zasięgu pod koniec długiego dnia wysyła swoją pracę, zamiast wpatrywać się w pasek postępu.

Dwóch geodetów otwiera tę samą latarnię. Jeden poprawia wysokość, drugi zapisuje typ oprawy. Przy synchronizacji na poziomie wierszy to konflikt, w którym jeden z nich traci popołudnie pracy. Tu obie zmiany zostają, bo serwer ustala, które kolumny faktycznie się zmieniły, i zapisuje każdą z nich. Geometria liczy się jako jedno pole, bo połowa położenia to żadne położenie.

Kiedy to samo pole naprawdę dostaje dwie różne wartości, zostaje ta, która pierwsza dotarła do serwera. To zasada wybrana świadomie, a nie dla wygody: alternatywą byłoby rozstrzyganie sporu zegarem urządzenia, a zegary w telefonach mylą się na tyle często, że „wygrywa późniejsza zmiana” po cichu znaczyłoby „wygrywa ten, kto ma źle ustawioną strefę czasową”.

Odrzucona wartość nie znika. Staje się zapisem konfliktu: obie wartości, które urządzenie co wysłało i kiedy, a kierownik przegląda takie zapisy w portalu. Synchronizacja może podjąć decyzję, ale nigdy nie może sprawić, że czyjaś praca zniknie. Edycja obiektu, który ktoś inny usunął, to ta sama historia od drugiej strony: usunięcie zostaje w mocy, a edycja jest zachowana, zamiast po cichu przywracać wiersz do życia.

Zlecenia się zmieniają. W drugim tygodniu okazuje się, że potrzebna jest kolumna, której nie było w pierwotnym formularzu, a w większości systemów oznacza to nowy plik dla wszystkich i wieczór spędzony na upewnianiu się, że nikt nie pracuje już na starym. Tu kierownik zmienia strukturę, wydaje ją, a zmiana dociera jako łatka: telefony dodają nową kolumnę i zachowują wszystko, co już mają, łącznie z danymi zebranymi tego ranka i jeszcze niewysłanymi.

Zmiany, które tylko dodają, przechodzą. Zmiana nazwy pola, zmiana jego typu albo usunięcie warstwy, do której ktoś wciąż zbiera dane, są odrzucane przy wydaniu z podaniem powodu, bo właśnie takie zmiany zostawiają czyjąś pracę bez miejsca, a odmowa, którą można przeczytać, jest lepsza niż migracja, o której dowiadujesz się po fakcie.

Aplikacja działa bez konta i bez sieci; działała tak, zanim cokolwiek z tego powstało. Synchronizacja to coś, co projekt robi, gdy trafi się połączenie warte użycia, a zbieranie danych na nią nie czeka. Wysyłka nie jest też nigdy odrzucana dlatego, że projekt zbliża się do limitu rozmiaru: to nie zespół ustalał ten limit, a niszczenie dnia pracy w terenie przez czyjąś regułę rozliczeniową to cena, której nie zamierzamy płacić. Zamiast tego ostrzeżenie dostaje kierownik.