Alinear los nombres de salida de las vistas con las columnas base renombradas en 76 (expte_alta/expte_baja/fecha_alta)
ALCANCE MEDIDO 2026-08-20 (el '6 vistas' original era incorrecto; hay DOS numeros y son preguntas distintas - etiquetarlos o el proximo lector elige uno y se equivoca): (A) DEPENDEN de las 3 columnas renombradas por 76 paso 3 (medido con pg_depend en PROD, db02): 5 vistas - v_vehiculo_historial, v_vehiculos_lineas_entidades, v_vehiculo_cadena, v_vehiculos_detalle, v_vehiculos_hist_ultimo. Las ultimas 3 consumen las columnas sin republicar el nombre viejo, asi que una busqueda por nombre de SALIDA no las ve. 'Que vistas exponen vocabulario viejo' y 'que vistas se rompen si la columna se mueve' son preguntas distintas; este ticket necesita las dos. (B) PUBLICAN nombres viejos originados en vehiculo_historial: 2 vistas. FUERA DE ALCANCE, confirmado en prod: v_vehiculos_export.expediente_baja viene de vehiculos_datos_colectivos (columna propia, nunca renombrada) y v_chofer_historial.expediente viene de chofer_historial. Cinco tablas tienen una columna 'expediente' y 76 solo renombro la de vehiculo_historial. PLAN, dos ramas distintas para las 2 vistas desalineadas: 1) v_vehiculos_lineas_entidades.expediente -> expte_alta. HACER. Cero consumidores EN src/ (repositories/vehiculos.ts:888-898 la lee con proyeccion explicita de 5 columnas y expediente no esta), 0 vistas/matviews/funciones dependen de ella, y NO es el campo del contrato OpenAPI (components.ts:598/605 lo alimenta linea_entidad_asignaciones, otra tabla). Usar ALTER TABLE public.v_vehiculos_lineas_entidades RENAME COLUMN - es metadata-only y CONSERVA LOS GRANTS; DROP+CREATE los pierde (MOBAAPI-600 sobre esta misma vista tuvo que re-emitir el GRANT a svc_nextjs). NO decir 'cero consumidores' a secas: la vista tiene 9 grants sobre 3 roles, incluido audit_ro con SELECT, cuyas consultas nadie relevo. ACOPLE CON PASO 4: 2026-08-20-movilba-76-paso4-...-DEV.sql:90 le saca estado_id a esta misma vista, o sea la reconstruye. Si 82 renombra ahora y el CREATE del paso 4 sigue diciendo 'expediente', el rename se revierte en silencio. Hay que escribir expte_alta en el script del paso 4 en el mismo momento, o plegar el rename dentro del paso 4. 2) v_vehiculo_historial (expediente, expediente_baja, fecha_expediente). DIFERIR, y el motivo correcto NO es el que decia la version anterior de este ticket. Drizzle .select() sin proyeccion NO emite SELECT *: emite la lista de columnas del schema TS. Entonces renombrar las salidas no filtra columnas a la UI - TIRA LA FICHA con 500 hasta que introspect.sh regenere drizzle/schema.ts y el codigo viaje en el MISMO deploy (reference_no_gate_consumes_the_app_schema_file: ningun gate de base lee schema.ts). Y la ficha es uno de los tres checks que NO se pueden ejercitar en prod: no existe login de app en prod. Ademas fecha_expediente no es solo una etiqueta: es la CLAVE DE ORDEN del historial. actions/vehiculos.ts:269 repite el ORDER BY porque Drizzle envuelve la vista y el ORDER BY de la vista no sobrevive. Renombrarla toca comportamiento de orden. Consumidores reales del nombre viejo: HistorialItem (actions/vehiculos.ts:136-142), el orderBy de :269, ExpedienteForm.tsx:501/535-536 y vehiculos/[id]/page.tsx:561-566. Nada de esto se aplica sin GO propio. Ratificado por audit-mba-l-ca, db02-mba-l-cc y db03-mba-l-ca.
Activity
-
coder02-mba-l-cc / coder
-
coder02 arranca por orden de Elazar (CLI 12:0x). Empiezo por medir: las 6 vistas, sus consumidores en src/, y cuales de esos nombres de salida son contrato publicado de la API v1 (SOTAMIT) y por lo tanto NO se pueden renombrar sin coordinacion externa.
-
was: MOVILBA-76 paso 3 renombro las columnas base de vehiculo_historial a expte_alta/expte_baja/fecha_alta, pero las 6 vistas conservan deliberadamente los nombres de salida VIEJOS con alias explicitos (vh.expte_alta AS expediente, vh.fecha_alta AS fecha_expediente, vh.expte_baja AS expediente_baja). Fue la decision correcta para 76: el paso 4 cambia UNA sola cosa y un rename de salida no viaja de polizon. PERO deja la base y la vista discrepando de forma permanente: el mismo campo se llama expte_alta en la tabla y expediente en la vista. Esa es exactamente la forma que nos mordio 7 veces la noche del 08-20 (un identificador, dos significados segun la superficie). Este ticket la cierra: renombrar las salidas de las 6 vistas Y mover los consumidores de la app en el MISMO deploy. No es urgente, SI es obligatorio - no dejarlo indefinido. Alternativa explicita si se decide NO hacerlo: documentar el mapeo en el .md de la vista para que nadie lo derive.
-
--reason
-
Parte 1 shippeada: v_vehiculos_lineas_entidades emite expte_alta en prod+dev (gates OK, audit clean, GO Elazar 21:34, v5.3.242 aprox). Quedan v_vehiculo_historial (rename de salida 500ea la ficha hasta introspect - va con paso 4) y el jsonb de v_vehiculos_detalle (contrato SOTAMIT congelado). Reabierto a todo porque el titulo cubre las vistas restantes.
-
RAMA 1 SHIPEADA 2026-08-20 21:34 (prod) y en dev: v_vehiculos_lineas_entidades emite expte_alta, ALTER TABLE ... RENAME COLUMN metadata-only, 4 gates verdes, GRANTs intactos (9 sobre 3 roles), audit CLEAN pre-apply, GO de Elazar en CLI. El acople con paso 4 quedo cerrado: el CREATE del script de paso 4 se parcheo a 'AS expte_alta' en el mismo commit, asi que una recreacion ya no revierte el rename. MEDIDO EN PROD 2026-08-21 08:1x: el bloque (B) baja de 2 vistas a UNA - solo queda v_vehiculo_historial con expediente/expediente_baja/fecha_expediente. Se re-confirmo que v_vehiculos_export.expediente_baja sale de vdc.expte_baja (fuera de alcance, el ticket ya lo decia bien) y que las 5 vistas de chofer/linea con 'expediente' vienen de otras tablas. RAMA 2 (v_vehiculo_historial) sigue DIFERIDA por el mismo motivo, sin cambios.
-
parent=MOVILBA-125
-
coder02 2026-09-04: remaining branch (view output names) is absorbed by MOVILBA-242 batch A - the rename of fecha_vigencia_* to fecha_alta/fecha_baja carries the view aliases with it; do not do it separately. Item stays todo, sequenced behind 242.
-
Duplicate execution path: remaining view-output rename is already absorbed by MOVILBA-242 batch A. Keeping this item open would create parallel ownership.