Deriva de esquema DEV vs PROD: censo completo de objetos y plan de convergencia
Elazar, CLI 2026-09-18, directo: 'prod can't have a different view than dev. dev and prod should be exactly the same. we develop in dev and deploy to prod. if there is a drift you have to fix it.' La deriva es un DEFECTO a cerrar, no un hecho a esquivar midiendo cada lado por separado. Disparador (MOVILBA-472, db03 midiendo dependientes de v_vehiculos_export_vdc): rutap/public divergen en al menos dos objetos. - v_vehiculos_export_periodo_actual: existe en DEV, NO existe en PROD. - v_vehiculos_vivos_estado: aparece como dependiente en PROD y no en la lista de DEV; duena postgres, con grants (role numericos + movilba_readonlyusergroup + svc_nextjs + nossesmacchia + penql) que no se parecen al par de elazar. Evidencia del disparador: /data-lezama/movilba/evidencia/MOVILBA-472/2026-09-18-472-prod-dependientes-y-acl.txt Alcance de ESTE item: el CENSO COMPLETO, no los dos objetos que aparecieron por casualidad. Dos objetos encontrados de costado significan que nadie comparo nunca los inventarios enteros. 1. Inventario por lado y diff, para public y rutap: vistas (pg_views), funciones (pg_proc), triggers (pg_trigger), tablas y columnas (pg_attribute: attname + atttypid + attnotnull), indices, constraints. Solo-en-DEV, solo-en-PROD, y presentes-en-ambos-con-cuerpo-distinto. 2. TRAMPA OBLIGATORIA: DEV corre PG 15.17 y PROD PG 17.6, y los dos imprimen el mismo cuerpo distinto (PG15 escribe s.col, PG17 omite el alias). Un diff crudo de pg_get_viewdef entre majors NUNCA da vacio. Normalizar antes de comparar o comparar por efecto; un diff no-vacio no es prueba de deriva. Ver memoria reference_pg15_y_pg17_imprimen_el_mismo_cuerpo_distinto... 3. Para cada objeto divergente, clasificar: (a) falta en PROD y hay que portarlo, (b) sobra en PROD y hay que borrarlo, (c) existe en ambos con cuerpo distinto y hay que decidir cual es el correcto. No proponer convivencia: se porta TODO y se BORRA lo deprecado. 4. Incluir relacl por objeto en los dos lados. Los grants tambien son deriva y una vista recreada vuelve sin ninguno. 5. Entregable: un .md en docs/reference/ con el censo y el plan de convergencia, mas los artefactos SQL. Sin valores volatiles en el .md mas alla del censo fechado. SELECT only en los dos lados para este item. La convergencia se aplica despues, por artefacto, con auditoria.
Activity
-
STARTED MOVILBA-479 at 2026-09-18 02:43:39 -0300
-
Elazar, CLI 2026-09-18, correccion a la regla de clasificacion: 'if prod got an anhanced feature than dev by some strange set of circumstances then you apply it in dev'. La convergencia NO tiene una direccion fija. DEV no es automaticamente la version correcta por ser donde se desarrolla: si PROD trae algo que DEV no tiene y ese algo es mejor o simplemente correcto, se PORTA A DEV, no se borra de PROD. La clasificacion (b) del alcance original -'sobra en PROD y hay que borrarlo'- queda partida en dos: (b1) sobra en PROD porque es residuo y se borra, (b2) existe solo en PROD porque es una mejora real y se porta a DEV. Para cada objeto solo-en-PROD hay que decidir explicitamente entre b1 y b2 ANTES de proponer un DROP, y dejar la razon escrita. Un objeto que nadie puede explicar no es automaticamente residuo. Caso concreto ya en la mesa: v_vehiculos_vivos_estado existe en PROD y no en DEV - no se borra hasta saber que hace y quien lo lee.
-
Censo completo entregado: docs/reference/movilba-479-dev-prod-schema-census.md + tools/movilba-479-census.sql + tools/movilba-479-normalize-viewdef.py + tools/movilba-479-census-diff.py. Evidencia fechada en /data-lezama/movilba/evidencia/MOVILBA-479/. Documentadas 2 trampas nuevas de impresora PG15/17 (constraintdef, functiondef) ademas de la ya conocida de viewdef. Hallazgo principal: rutap.proyectar_snapshot difiere en contenido real (no solo formato) entre DEV y PROD - escalado a coder03, metodo de resolucion por provenance ya fijado, sin aplicar. Tabla de items sin clasificar (7) queda en el doc para que coder03 filie hijos si corresponde.
-
db02-mba-l-cc, 2026-09-18: item senalado por coder03 tras cerrar 342 (drift residual en rutap.proyectar_snapshot post-provenance-merge, solo comentarios - 25 lineas de comentarios en PROD ausentes en DEV, cuerpo ejecutable ya identico). Verificado independiente: diff crudo de pg_get_functiondef entre DEV y PROD, 33 lineas, TODAS comentarios, cero contenido ejecutable. Aplicado: CREATE OR REPLACE FUNCTION en DEV con el cuerpo exacto de PROD (docs/migrations/2026-09-18-movilba-479-proyectar-snapshot-comment-parity-DEV.sql). Verificado post-apply: pg_get_functiondef de DEV y PROD ahora es BYTE-IDENTICO (diff vacio). No hay nada pendiente en pending-prod-changes.md porque el contenido ya estaba en PROD - esto solo llevo la documentacion a DEV.
-
Deriva NUEVA de DEV/PROD encontrada por db03-mba-l-cc el 2026-09-23 al preparar el reemplazo de v_vehiculos_detalle para MOVILBA-145b, medida contra el cuerpo instalado de cada base (credito a db03, no a coder03): v_vehiculos_detalle NO ES LA MISMA VISTA en las dos bases. DEV joinea v_vehiculos_hist_ultimo current_period y rutap.vehiculo_historial_normalizado periodo_veh, y lee COALESCE(periodo_veh.aire_acondicionado_id, ca.carroceria_aire_acondicionado_id) y COALESCE(periodo_veh.piso_id, ca.carroceria_piso_id). PROD no tiene NINGUNO de los dos joins y lee ca.carroceria_aire_acondicionado_id y ca.carroceria_piso_id directo. O sea a PROD le falta el overlay de periodo que DEV si tiene para aire acondicionado y piso. db03 cambio SOLO la proyeccion de fecha_ultima_actualizacion en cada base contra el cuerpo propio de esa base y NO convergio el overlay dentro de ese artefacto - correcto: converger ahi habria cambiado en silencio lo que PROD muestra para aire y piso, bajo un ticket que era sobre una fecha. Converger este overlay es una decision aparte y vive aca.
-
MOVILBA-750 supersedes historical 'PROD agents artifact pending' reading: 2026-08-24 migration explicitly made agents.v_vehiculo_lookup DEV-only agent convenience, and 2026-09-18 DEV migration preserved it. PM 2026-10-08 invokes parity-rule exception for agents schema. Census clarification lives in docs/reference/movilba-585-dev-prod-structural-census.md SHA256 64d89ab7; no PROD CREATE/DEV DROP owed.
-
CORRECTION to prior MOVILBA-750 parity note: the DEV-only exception covers agents.v_vehiculo_lookup only. The second agents invariant view lacks a creation-migration citation and is now removal candidate MOVILBA-757, with no DROP/CREATE authorized. Revised MOVILBA-585 census SHA256 90caa1f7 supersedes 64d89ab7.