Un programador relata cómo, tras meses preparando una migración con la aprobación de todos los stakeholders, descubrió commits manuales dispersos por el código que rompían la atomicidad de las transacciones. El artículo no critica a los ORM, ni a las consultas parametrizadas ni a los query builders, sino un problema de organización: llamadas a commit() escondidas a dos o más niveles de profundidad dentro de métodos auxiliares, lo que impide que el gestor de transacciones agrupe las escrituras como una sola unidad atómica. Mediante ejemplos en Python, el autor describe tres patrones peligrosos: el "enemigo oculto" (commits manuales dentro de helpers), el "enemigo silencioso" (modelos de la capa de base de datos que, al modificar una propiedad, disparan escrituras invisibles) y la "vuelta del lechero" (código sin transacciones que provoca pérdida de datos). La solución propuesta es concentrar toda la lógica de sesiones, commits y transacciones en una única capa de abstracción de acceso a datos, y dejar que solo ella se encargue de abrir, cerrar y confirmar operaciones. Para evitar regresiones, el texto sugiere imponer reglas con AST o flake8 que prohíban commits manuales, accesos a sesiones y modelos de BD fuera de esa capa. Cuando la regla no pueda expresarse de forma estática —por ejemplo, detectar que una función devuelve un modelo de BD en lugar de un modelo de dominio— se recurre a un paso de LLM en CI/CD que genera un veredicto y deriva los casos dudosos a revisión humana. La idea central: la capa de abstracción de base de datos posee los commits y las transacciones; cualquier desviación obligará a refactorizar meses de código.
Noticias agregadas con IA