Actualizar sin miedo: tus archivos se abren igual

Segunda entrega de la serie «Por dentro de KapyCAD 2». En la primera contamos cómo probamos KapyCAD para cazar los bugs que no se ven. No romper tus archivos es un compromiso que exige mucho trabajo silencioso, y de eso trata esta entrega.

El miedo a actualizar

Si llevas tiempo con programas de CAD, conoces la sensación. Sale una versión nueva, actualizas y abres aquel soporte que diseñaste hace unas semanas. Y algo no cuadra. Un agujero que estaba centrado ya no lo está. Un redondeo ha desaparecido. Una operación sale en rojo con un error que no habías visto nunca.

A veces el programa te avisa: «este archivo se ha convertido al nuevo formato». Y tú piensas: ¿convertido a qué?, ¿qué ha tocado?

Es un miedo razonable. Si abres un documento de Word con una versión nueva, lo peor que suele pasar es que un salto de página caiga en otro sitio; el texto sigue siendo el mismo. Un archivo de CAD es una receta de geometría: si una sola instrucción se lee distinto, la pieza que sale es otra. Y casi nunca lo descubres al abrirla, sino al imprimirla.

Lo que prometemos es esto: abres un archivo viejo y es exactamente la misma pieza.

Un archivo con versión

KapyCAD no ha dejado de cambiar. Cada vez que añadimos una operación nueva, una restricción o un tipo de patrón, o arreglamos cómo se guarda algo, el formato del archivo cambia un poco. En estos meses de desarrollo, el formato ha cambiado unas cincuenta veces.

Para que eso no te afecte, cada documento lleva escrito con qué versión del formato se guardó: un simple número.

Cuando abres un archivo, KapyCAD mira ese número y lo compara con la versión que él entiende. Si son la misma, se lee tal cual. Si el archivo es más viejo, entra en juego la cadena de migraciones: una lista de pasos, uno por cada cambio de formato. El paso 1 lleva un documento de la versión 1 a la 2; el paso 2, de la 2 a la 3, y así hasta la actual.

diagram

Un archivo guardado con una versión anterior sube la escalera peldaño a peldaño hasta la versión actual, por los mismos pasos que recorrió en su día el formato. Cada paso solo tiene que saber hacer una cosa, pasar de la versión N a la N+1, y ninguno necesita conocer la cadena entera.

La migración, además, ocurre en memoria, al abrir. Tu archivo guardado no se reescribe por abrirlo; solo cuando guardas de nuevo se escribe en el formato actual.

Pasos puros

Un paso de migración tiene que ser puro: recibe el documento y devuelve el documento.

• No lee nada de fuera: ni la red, ni tus preferencias, ni otros archivos.
• No guarda nada para después.
• No mira el reloj.
• Y, sobre todo, no recalcula geometría. No resuelve croquis, no llama al kernel, no regenera sólidos.

Lo del reloj tiene su historia. Hubo un cambio de formato que añadió un cajetín a los planos, y el cajetín lleva fecha. A un plano creado al migrar le toca la fecha de hoy, pero si el paso mirara el reloj por su cuenta, el mismo archivo daría resultados distintos según el día en que lo abrieras, y eso sería imposible de probar. Así que el paso no mira el reloj: quien lo llama le dice qué día es.

No recalcular geometría importa todavía más. Un paso transforma los datos del documento: renombra un campo, añade una lista vacía donde antes no había nada, quita una clave que ya nadie lee. Por ejemplo, el paso de la versión 1 a la 2 se limita a darle a cada croquis una lista de patrones vacía, porque los patrones aún no existían cuando se guardó.

Y cuando un cambio de formato podría cambiar la forma de una pieza, el paso se encarga de que no lo haga. Un ejemplo real: durante un tiempo, las operaciones de offset guardaban un tipo de unión que en realidad nunca se leía, porque el cálculo siempre usaba la misma. Cuando empezamos a respetar ese campo, el paso de migración lo fijó en la unión que se había usado hasta entonces, para que cada pieza guardada siga teniendo la forma que tenía.

También exigimos que cada paso sea idempotente: pasarlo dos veces sobre el mismo documento tiene que dar lo mismo que pasarlo una, así que da igual si un paso se aplica dos veces por error.

Abrir no mueve nada

Los pasos puros se ocupan de los datos. Después de migrar, el documento se abre del todo: se resuelven los croquis y se reconstruyen los sólidos. Y ahí hay otra trampa.

Un croquis guardado es la respuesta que dio el solver la última vez que lo editaste. Si al abrirlo el solver decidiera resolverlo «otra vez, a su manera», podría encontrar otra solución igual de válida y moverte un punto sin que hayas tocado nada.

Por eso hay una regla que está por encima de casi todo: la geometría guardada manda. Si las restricciones de un croquis ya se cumplen tal y como está, resolverlo al abrir no mueve ningún punto. Como contamos en la primera entrega, un juez lo vigila sobre el corpus de 602 croquis con una tolerancia de diez nanómetros.

Como abrir no cambia nada, la huella del documento tampoco cambia. El autoguardado no ve cambios fantasma, y tu historial no se llena de versiones que nadie ha tocado.

Solo en un sentido

La cadena tiene una dirección. Un archivo viejo se abre en una versión nueva, pero un archivo nuevo no se abre en una versión vieja.

Una versión vieja no sabe qué hacer con lo que todavía no existía cuando se escribió. Si se encontrara un campo nuevo, como el lado de una tangencia, tendría dos opciones malas: ignorarlo y resolver el croquis a su manera, con riesgo de darte otra pieza, o intentar adivinar qué significa. Las dos acaban igual: una pieza distinta de la que guardaste, y sin avisarte.

Así que, si el archivo es de una versión más nueva que la que entiende, se niega a abrirlo y te dice por qué. Preferimos un «no puedo abrir esto» claro a un archivo abierto mal en silencio. Es la misma filosofía que con las referencias a caras, que explicamos en El problema de nombrar caras: si algo no se puede resolver bien, el error se muestra.

Cómo lo probamos

Para comprobarlo usamos una de las herramientas de la primera entrega: un oráculo congelado.

Antes de mover la cadena de migraciones a su sitio nuevo, juntamos todos los documentos que pudimos. Entraron todos los archivos de ejemplo y de prueba del proyecto, en todas las versiones del formato por las que han pasado, y todas las versiones guardadas de nuestra base de datos de desarrollo (en local, nunca la de producción), que tiene documentos guardados con muchas versiones distintas del formato. Sumamos los documentos que construían a mano los tests de migraciones que ya teníamos y, por último, documentos sintéticos escritos para los pasos más antiguos: el documento más viejo de nuestra base de datos ya era de la versión 30, y los primeros veintinueve pasos merecían algo más que un par de ejemplos.

En total, 6256 documentos. Cada uno se pasó por la cadena antigua paso a paso, y se grabó el resultado después de cada paso: 47 232 respuestas.

La cadena nueva tiene que dar los mismos bytes, documento a documento y paso a paso. Si algo difiere, el juez señala qué documento, qué paso y qué campo.

Exigir los mismos bytes sacó a la luz detalles que nadie habría buscado: el orden en que aparecen las claves, cómo se redondea un número al escribirlo y volverlo a leer, campos que desaparecen sin hacer ruido, la diferencia entre cero y «menos cero», y el último bit de un cálculo de longitud.

La cadena antigua ya no existe; la grabación sí y, como contamos en la primera entrega, tiene su control rojo.

Lo que significa para ti

Puedes actualizar sin miedo a perder tus piezas. Tus archivos llevan su versión, suben la escalera de pasos puros al abrirse, y al llegar arriba el editor respeta la geometría tal como la dejaste. Nada se recalcula a tus espaldas, nada se escribe en tu archivo hasta que tú lo editas, y si algún día un archivo no se puede abrir, te lo diremos con claridad. Solo ten en cuenta que, una vez guardado en KapyCAD 2, el archivo ya no vuelve a la versión actual.

En la tercera entrega pasamos al kernel de geometría: por qué compilamos y mantenemos nuestro propio OpenCascade.