Projektsynchronisierung

Ein Mapit-Projekt ist ein GeoPackage: eine Datei mit den Layern, den Formularen dahinter und allem, was darin erfasst wurde. Wenn ein Projekt in die Cloud geht, bleibt diese Datei, was sie ist, und die Kopie auf dem Server ist diejenige, auf die alle zusammenlaufen. Nichts wird in eine Datenbank zerlegt, die sich nur über uns wieder auslesen lässt. Deshalb ist die Antwort auf „Können wir unsere Daten haben?“ ein Download und kein Supportticket.

Was übertragen wird, ist nicht die Datei. Ein Telefon, das das Projekt bereits hat, sendet die Zeilen, die es geändert hat, und empfängt die Zeilen, die alle anderen geändert haben. Die erste Synchronisierung bewegt also ein Projekt, und jede weitere nur noch ein Gespräch. Deshalb sind die zweite und die zweihundertste Synchronisierung beide klein, und deshalb bekommt ein Team mit schwacher Verbindung am Ende eines langen Tages seine Arbeit weg, statt einem Fortschrittsbalken zuzusehen.

Zwei Vermesser öffnen denselben Lichtmast. Einer korrigiert die Höhe, der andere erfasst den Leuchtentyp. Bei zeilenweiser Synchronisierung wird daraus ein Streit, und einer von beiden verliert seinen Nachmittag. Hier kommen beide Änderungen an, weil der Server ermittelt, welche Spalten sich tatsächlich geändert haben, und jede einzeln übernimmt. Die Geometrie zählt als ein einziges Feld, denn eine halbe Position ist keine Position.

Wenn dasselbe Feld wirklich auf zwei verschiedene Werte gesetzt wird, gilt der Wert, der zuerst den Server erreicht. Diese Regel ist bewusst gewählt und nicht bequem: Die Alternative wäre, die Uhr eines Geräts entscheiden zu lassen, und Telefonuhren gehen oft genug falsch, dass „die spätere Änderung gewinnt“ stillschweigend bedeuten würde: „wer die falsche Zeitzone eingestellt hat, gewinnt“.

Der verworfene Wert wird nicht verworfen. Er wird zu einem Konfliktdatensatz mit beiden Seiten, welches Gerät was gesendet hat und wann, und ein Manager entscheidet im Portal, welche Version gilt. Eine Synchronisierung darf eine Entscheidung treffen, aber sie darf niemals Arbeit verschwinden lassen. Ein Feature zu bearbeiten, das jemand anderes gelöscht hat, ist dieselbe Geschichte von der anderen Seite: Die Löschung bleibt bestehen und die Bearbeitung wird aufbewahrt, statt dass eine Zeile stillschweigend wieder zum Leben erwacht.

Aufträge ändern sich. In der zweiten Woche braucht jemand eine Spalte, die im ursprünglichen Formular nicht vorgesehen war, und in den meisten Systemen bedeutet das eine neue Datei für alle und einen Abend, an dem man sicherstellt, dass niemand mehr mit der alten arbeitet. Hier ändert ein Manager die Struktur, gibt sie frei, und die Änderung kommt als Patch: Die Telefone übernehmen die neue Spalte und behalten alles, was bereits darauf ist, einschließlich der Arbeit, die am Morgen erfasst und noch nicht gesendet wurde.

Ergänzende Änderungen gehen durch. Ein Feld umzubenennen, seinen Typ zu ändern oder einen Layer zu entfernen, in den noch erfasst wird, wird bei der Freigabe mit Begründung abgelehnt, denn genau diese Änderungen lassen Arbeit ins Leere laufen, und eine Ablehnung, die man lesen kann, ist besser als eine Migration, die man hinterher entdeckt.

Die App funktioniert ohne Konto und ohne Empfang; das tat sie schon, bevor es all das hier gab. Synchronisieren ist etwas, das das Projekt tut, wenn eine brauchbare Verbindung da ist, und nichts am Erfassen wartet darauf. Ein Hochladen wird auch nie abgelehnt, weil ein Projekt kurz vor seiner Größengrenze steht: Das Team hat das Kontingent nicht festgelegt, und einen Tag Feldarbeit wegen der Abrechnungsregel eines anderen zu vernichten, ist kein Tausch, den wir eingehen. Stattdessen wird der Manager gewarnt.