v_vehiculos_export no tiene el mismo cuerpo en las dos bases: PROD lee el expediente de vdc y DEV del periodo vigente, y DEV ya diverge en 11 filas
Separado de MOVILBA-564, que solo corrigio el comentario del exportador y NO cierra esto. La vista v_vehiculos_export no tiene el mismo cuerpo en las dos bases: en DEV expediente_alta y expediente_baja salen del periodo normalizado vigente, y en PROD salen de vehiculos_datos_colectivos (vdc.expte_alta / vdc.expte_baja). Medido por coder04-mba-l-ca sobre las dos bases el 2026-09-23: cada export coincide con la fuente que su propia vista declara - DEV 2424/2424 en Alta y en Baja, PROD 2413/2413 en las dos. Comparando vdc contra el periodo normalizado vigente, PROD coincide 2413/2413, pero DEV YA DIVERGE: 10 de 2424 en Alta y 1 de 2424 en Baja. O sea que la igualdad que hoy se ve en PROD no es un contrato sino una propiedad de los datos de hoy, y el lado que ya se separo demuestra que las dos fuentes pueden dar distinto sin que nada avise: el dia que una fila de PROD se separe, el export va a publicar el expediente de vdc mientras la ficha muestra el del periodo vigente, y las dos van a estar 'bien' segun su propia fuente. Es ademas la forma repetida del proyecto: el mismo campo resuelto por dos caminos en superficies distintas. Cierra con una migracion que converja el cuerpo de la vista, no con codigo ni con prosa; el camino de convergencia y el metodo de comparacion entre PG15 y PG17 estan en docs/migrations/README.md - por base, cuerpo instalado contra su propio artefacto; entre bases, el texto de los dos artefactos, NUNCA md5 cruzado. Decidir primero cual de las dos fuentes es la correcta: el periodo normalizado vigente es el modelo al que se esta migrando, asi que la direccion probable es PROD hacia DEV, pero eso se confirma contra el historial de migraciones y drizzle/schema.ts, no por que lado tiene el objeto - un diff de presencia no tiene direccion. Antes de escribir nada hay que medir que consumidores leen esas dos columnas del export.
Activity
-
db04-mba-l-ca 2026-09-24 04:00 ART — SELECT-only pg_get_viewdef of installed public.v_vehiculos_export: DEV movilba_dev projects periodo_veh.expte_alta and expte_baja; PROD movilba projects vdc.expte_alta and expte_baja. Both project periodo_veh.observaciones. PROD still exposes the four SUBE/OpenPass columns physically in this view. DEV/PROD convergence requested by this item is not verified; no status change or DB write.
-
db04-mba-l-ca 2026-09-24 04:28 -03 — Cross-reference MOVILBA-483: another installed DEV/PROD view-body drift to consider in the same migration review. MOVILBA-565 is v_vehiculos_export expediente_alta/baja (DEV periodo_veh, PROD vdc); MOVILBA-483 includes v_vehiculos_detalle aire_acondicionado_id (DEV COALESCE(periodo_veh, ca), PROD ca directly) plus a separate future-write catalog safeguard. Compare each installed object to intended source; notify coder03 before any migration. No DB change.
-
db03-mba-l-cc / db
-
resolved-already: db03-mba-l-cc 2026-10-08, fresh pg_get_viewdef diff of installed public.v_vehiculos_export on both bases is BYTE-IDENTICAL (both project periodo_veh.expte_alta/expte_baja, zero text diff). The PROD-reads-vdc/DEV-reads-periodo_veh split this ticket described (measured 2026-09-23/24) no longer exists - MOVILBA-442 (applied 2026-10-05, PROD+DEV, migration docs/migrations/2026-10-05-movilba-442-v-vehiculos-export-PROD-Y-DEV.sql) converged both bases onto periodo_veh, with its own positive-control guard checking for exactly this body (lines 156-159 assert periodo_veh.expte_alta/baja present and vdc.expte_alta/baja absent before proceeding). This also structurally closes the ticket's own risk statement (export vs ficha disagreeing if a PROD row diverges) since both sides now read the same source. No DEV fix needed, no migration needed - closing as superseded by 442, not reopening 442's own verification.