sqlite-utils 4.0rc3: claves foráneas compuestas antes de la versión estable

Simon Willison quería publicar este fin de semana la versión estable de sqlite-utils 4.0. En su lugar, el 5 de julio llegó una tercera release candidate: sqlite-utils 4.0rc3. El motivo, cuenta el propio autor, es que el changelog desde la rc2 no dejaba de crecer mientras vaciaba la cola de issues y pull requests con la ayuda de Claude Fable 5 y de un segundo asistente de código de frontera, según cuenta en su blog.

Para quien no la conozca, sqlite-utils es una de esas herramientas discretas que sostienen medio ecosistema de datos: una librería de Python y una CLI para crear, transformar y consultar bases de datos SQLite, y la pieza sobre la que se apoya Datasette, el proyecto de publicación de datos del propio Willison. Un salto de versión mayor aquí no es un trámite: hay miles de scripts, cuadernos y pipelines que dependen de su API desde hace años. La 4.0 lleva gestándose a lo largo de varias release candidates, y cada una ha ido acumulando cambios que el autor no quería dejar fuera de la estable.

Claves foráneas compuestas, el cambio que obligaba a esperar

La novedad principal de la rc3 es el soporte para introspeccionar y crear claves foráneas compuestas, las que referencian varias columnas a la vez. Según explica Willison, la funcionalidad implica un cambio sutil pero incompatible en table.foreign_keys, la API de Python que expone las relaciones de una tabla. Y ahí está la razón del retraso: un cambio que rompe compatibilidad tiene que entrar antes del 4.0 definitivo, porque después tocaría esperar a un hipotético 5.0. Es disciplina de versionado semántico aplicada con criterio, y explica que el autor prefiera una release candidate más antes que arrastrar el problema durante todo el ciclo de la versión 4.

Columnas que ya no distinguen mayúsculas

El segundo cambio de calado alinea la herramienta con una convención histórica de SQLite: los nombres de columna no distinguen mayúsculas de minúsculas. Parecía un ajuste menor y acabó tocando, según el changelog, un buen puñado de sitios a la vez. Es el tipo de cambio transversal que justifica por sí solo una release candidate adicional: fácil de enunciar, difícil de acotar.

Cómo se está haciendo también cuenta

Más allá de las funcionalidades, el proceso tiene interés propio. Willison lleva años documentando en público cómo usa asistentes de código, y aquí describe sin dramatismo una dinámica cada vez más común en el open source: un mantenedor veterano vaciando el backlog de un proyecto de casi una década con dos modelos de frontera trabajando en paralelo. El resultado no es código sin supervisión, sino más cambios revisados por release de los que una sola persona abordaría en un fin de semana. Que eso alargue el ciclo de release candidates en lugar de acortarlo dice bastante sobre dónde está el cuello de botella real: en decidir y verificar, no en teclear.

Qué hacer si dependes de sqlite-utils

Si usas la API de Python, revisa cualquier uso de table.foreign_keys: es el punto con cambio incompatible documentado.
Si tus pipelines asumen distinción de mayúsculas en los nombres de columna, prueba la rc3 ahora, antes de que el comportamiento nuevo llegue como estable.
* La release en GitHub detalla el resto de correcciones acumuladas desde la rc2.

Instalar una release candidate en un entorno de pruebas cuesta minutos y evita sorpresas cuando el 4.0 final llegue, algo que, visto el ritmo del proyecto, debería ser cuestión de días o semanas.

Desde ElephantPink seguimos de cerca este tipo de proyectos porque SQLite aparece en más rincones de nuestros despliegues de lo que solemos admitir. Una 4.0 que prefiere retrasarse a romper en silencio la API de sus usuarios es justo el estándar de mantenimiento que nos gustaría ver más a menudo.