Dev y prod no exportan lo mismo: v_vehiculos_export en dev esta dos decisiones atras
Medido 2026-08-20 07:50 con pg_get_viewdef en las dos bases. PROD: fecha_alta se deriva de rutap.v_rutap_latest_norm por chasis normalizado, y el WHERE no filtra estados. DEV: fecha_alta sigue siendo vdc.fecha_vigencia_desde AS fecha_alta, y el WHERE conserva op_estado.nombre_mostrable !~~* 'Baja%'. Son DOS decisiones de prod que dev no tiene: la derivacion por chasis del 2026-08-14 (docs/migrations/2026-08-14-export-fecha-alta-por-chasis.sql) y la reversion del filtro de bajas que ordeno Elazar el 2026-08-19 (docs/migrations/2026-08-19-export-incluye-bajas-con-fecha-alta.sql). CONSECUENCIA: quien prueba la descarga en dev01 obtiene un archivo distinto del que produce prod, en dos dimensiones a la vez, y nada falla ni avisa. CORRECCION IMPORTANTE (db02, 2026-08-20 07:52, y verificado por mi contra las dos bases): la primera version de este ticket decia que dev NO TIENE el schema rutap y que por eso la definicion de prod no se podia ni crear. ES FALSO y lo escribi sin medirlo. Dev SI tiene el schema rutap: rutap_rows, rutap.snapshots y rutap.v_rutap_latest, con 5086 filas y la misma lista de columnas que prod. Lo unico que le falta a dev son las vistas v_rutap_latest_norm y v_rutap_latest_empresas, y la definicion de v_rutap_latest_norm en prod lee de rutap.v_rutap_latest y nada mas, que dev ya tiene. O sea que la sincronizacion es UN CREATE VIEW sobre columnas identicas y el mismo snapshot, mas el CREATE OR REPLACE de v_vehiculos_export. NO ES UN IMPOSIBLE, es una migracion normal con un gate normal. Lo que sigue abierto es la DECISION, no la factibilidad: queremos que la descarga de dev sea espejo de la de prod, si o no. Si si, son dos objetos y necesita GO. Si no, hay que documentar que la descarga solo se valida contra prod y que probarla en dev01 no prueba nada. drizzle/schema.ts:2470 NO esta desactualizado: es fiel a dev, que es la base contra la que se introspecta, y no hay que regenerarlo contra prod.
Activity
-
was: Medido 2026-08-20 07:50 con pg_get_viewdef en las dos bases. PROD: fecha_alta se deriva de rutap.v_rutap_latest_norm por chasis normalizado, y el WHERE no filtra estados. DEV: fecha_alta sigue siendo vdc.fecha_vigencia_desde AS fecha_alta, y el WHERE conserva op_estado.nombre_mostrable !~~* 'Baja%'. Son DOS decisiones de prod que dev no tiene: la derivacion por chasis del 2026-08-14 (docs/migrations/2026-08-14-export-fecha-alta-por-chasis.sql) y la reversion del filtro de bajas que ordeno Elazar el 2026-08-19 (docs/migrations/2026-08-19-export-incluye-bajas-con-fecha-alta.sql). CONSECUENCIA: quien prueba la descarga en dev01 obtiene un archivo distinto del que produce prod, en dos dimensiones a la vez, y nada falla ni avisa. OBSTACULO REAL, no es un replace de una linea: dev NO TIENE el schema rutap, asi que la definicion de prod no se puede ni crear ahi. Decidir entre: dev gana una copia del snapshot rutap, la vista de dev usa una fuente degradada declarada como tal, o se acepta la divergencia y se documenta que la descarga solo se valida contra prod. drizzle/schema.ts:2470 NO esta desactualizado: es fiel a dev, que es la base contra la que se introspecta.
-
v_vehiculos_export en dev quedo byte-identica a la de prod tras el apply de db-mba-l-cc a las 11:02 (2026-08-20). Verificado ademas que el paso 3 de MOVILBA-76 (11:30) NO la afecta: la vista toca vehiculo_historial en un solo lugar, el subselect max(h.creado_en) para 'ultima_modificacion', y creado_en no se renombro; expte_alta/expte_baja del export salen de vehiculos_datos_colectivos, que ya tenia sus propias columnas y el paso 3 no toco. O sea que la definicion es la corriente tanto contra la prod de antes como la de despues del rename. El ticket quedo en backlog casi tres horas con el trabajo ya aplicado: se cierra ahora, no se re-hace.