Sincronización de proyectos

Un proyecto de Mapit es un GeoPackage: un solo archivo con las capas, los formularios que hay detrás y todo lo recopilado en ellas. Cuando un proyecto pasa a la nube, ese archivo sigue siendo lo que es, y la copia del servidor es aquella con la que todos convergen. Nada se despedaza en una base de datos que solo pueda leerse a través de nosotros, y por eso la respuesta a «¿podemos tener nuestros datos?» es una descarga y no una solicitud al soporte.

Lo que viaja no es el archivo. Un teléfono que ya tiene el proyecto envía las filas que ha cambiado y recibe las filas que han cambiado los demás, así que la primera sincronización mueve un proyecto y cada una de las siguientes mueve una conversación. Por eso la segunda sincronización y la número doscientos son igual de pequeñas, y por eso un equipo con poca cobertura al final de un día largo consigue enviar su trabajo en lugar de quedarse mirando una barra de progreso.

Dos técnicos abren la misma farola. Uno corrige la altura y el otro anota el tipo de luminaria. Con una sincronización por filas eso es una pelea y uno de los dos pierde su tarde; aquí se guardan los dos cambios, porque el servidor averigua qué columnas han cambiado de verdad y aplica cada una. La geometría cuenta como un solo campo, porque media posición no es una posición.

Cuando el mismo campo recibe de verdad dos valores distintos, se queda el primero que llega al servidor. Es una regla elegida, no una comodidad: la alternativa es dejar que decida el reloj del dispositivo, y los relojes de los teléfonos se equivocan tan a menudo que «gana la edición posterior» significaría en silencio «gana quien tenga mal configurada la zona horaria».

El valor descartado no se descarta. Se convierte en un registro de conflicto con las dos versiones, qué dispositivo envió cada una y cuándo, y un gestor decide en el portal qué versión se mantiene. Una sincronización puede tomar una decisión; nunca puede hacer desaparecer el trabajo de nadie. Editar una entidad que otra persona ha eliminado es la misma historia vista desde el otro lado: la eliminación se mantiene y la edición se conserva, en lugar de que una fila vuelva a la vida sin que nadie lo note.

Los trabajos cambian. En la segunda semana alguien necesita una columna que no estaba en el formulario original, y en la mayoría de los sistemas eso significa un archivo nuevo para todos y una tarde asegurándose de que nadie sigue con el antiguo. Aquí un gestor edita la estructura, la despliega y el cambio viaja como un parche: los teléfonos aplican la columna nueva y conservan todo lo que ya tienen, incluido el trabajo recopilado esa misma mañana y todavía sin enviar.

Los cambios que solo añaden pasan. Cambiar el nombre de un campo, cambiar su tipo o eliminar una capa en la que todavía se está recopilando se rechaza en el despliegue, indicando el motivo, porque esos son los cambios que dejan trabajo sin sitio, y un rechazo que puedes leer es mejor que una migración que descubres después.

La aplicación funciona sin cuenta y sin señal; ya lo hacía antes de que existiera nada de esto. La sincronización es algo que el proyecto hace cuando hay una conexión que merece la pena, y nada de la recopilación la espera. Un envío tampoco se rechaza nunca porque un proyecto se acerque a su límite de tamaño: el equipo no fijó esa cuota, y destruir un día de trabajo de campo por la regla de facturación de otra persona no es un precio que estemos dispuestos a pagar. En su lugar, se avisa al gestor.