Clase 308 adentro de la base: vistas con JOIN a opciones sin calificar por catalogo - v_vehiculo_historial tiene tres, y nadie barrio el resto
HALLAZGO de db02-mba-l-cc el 2026-09-18, leyendo pg_get_viewdef mientras media MOVILBA-308. MOVILBA-308 es la misma clase pero se acoto al CODIGO: sus nueve sitios son .ts. Este item es la mitad que quedaba afuera y que un grep sobre src/ no puede ver, que es exactamente el punto ciego ya registrado: grep no ve al consumidor que vive adentro de la base. EL DEFECTO, identico al de 308: opciones guarda MUCHOS catalogos en una sola tabla (regla permanente de Elazar). Un JOIN por o.id = <columna>_id sin el par (grupo_nombre, campo_nombre) resuelve un id mal apuntado a una etiqueta AJENA, plausible y confiada - sin error, sin NULL, sin nada que se note. SITIOS CONOCIDOS: public.v_vehiculo_historial trae TRES joins a opciones sin calificar - estado_id, motivo_id y tramite_id. No es el sitio de rutap-historial.ts:100 que ya se arreglo en v5.5.16: este vive adentro del sub-select de historial de v_vehiculos_detalle, o sea que sale en la ficha del vehiculo y en cualquier cosa que lea esa vista. IMPACTO HOY, medido por db02 en DEV y PROD con el split de tres (con_id_no_nulo / resolvia_a_otro_catalogo / id_inexistente) y con control positivo: CERO en las dos puntas. estado_id y tramite_id resuelven bien; motivo_id no tiene ninguna fila no-nula, o sea columna muerta sin riesgo hoy. Igual que en 308, el cero NO es porque este calificado - no lo esta - sino porque opciones.id es PK y los catalogos de hoy no chocan. Es profilactico, y ese es el motivo de arreglarlo: el modo se vuelve posible el dia que un id se re-apunte. LO QUE FALTA Y ES EL GRUESO DEL ITEM: nadie barrio el resto de las vistas. v_vehiculo_historial aparecio porque db02 estaba leyendo ESE viewdef, no porque exista un censo. La poblacion del item es TODAS las vistas que tocan opciones, enumeradas contra pg_get_viewdef / pg_depend, no contra grep. Hasta que ese censo exista, son tres sitios es una MUESTRA, no un conteo. COMO SE ARREGLA: el par (grupo_nombre, campo_nombre) de cada columna se ESTABLECE contra el catalogo y contra otros usos, NUNCA se adivina del nombre de la columna; y antes de calificar hay que medir contra que pares resuelve DE VERDAD la poblacion, porque una columna puede apuntar a DOS catalogos vivos a la vez - paso en el noveno sitio de 308 (clase_licencia_id) y ahi un par suelto VACIA las filas del otro catalogo en vez de mentir. DDL de vista: pg_depend antes, jamas CASCADE, y el cuerpo instalado se lee con pg_get_viewdef. DEV y PROD tienen que quedar iguales.
Sub-tickets — 2/3 done
Activity
-
db02-mba-l-cc / db
-
db02, census in progress via pg_depend (45 views depend on public.opciones). Two live findings escalated by DM to coder03+audit, not waiting for full census: (1) LIVE DATA BUG PROD: vdc.estandar_emisiones_id, 3 vehicles (vehiculo_id 5072/4564/4399) FK points at ('motor','tipo_motor') rows (id 153/154, E3/E5) instead of ('motor','estandar_emisiones') - v_vehiculos_detalle/v_vehiculos_export display the wrong catalog's label today, not a someday-risk. Qualifying the join alone won't fix content, just makes it go blank instead of wrong - needs a data decision on the correct id. (2) carrocerias.carroceria_aire_acondicionado_id id=70 (PROD) resolves against TWO live catalogs simultaneously (general.respuesta_binaria x69, carroceria.aire_acondicionado x1) - same UNION-needed shape as 308's clase_licencia_id. Remaining ~13 unpaired columns measured for real catalog resolution (not guessed): entidades.tipo_entidad_id->entidades.tipo_entidad, personas.tipo_persona_id->personas.tipo_persona, direcciones_postales.tipo_direccion_id->contacto.tipo_direccion, instalaciones.provincia_id->ubicacion.provincia, vehiculos.motor_unidad_propulsora_id->motor.unidad_propulsora, carrocerias.carroceria_piso_id/vhn.piso_id->carroceria.piso, vhn.aire_acondicionado_id + 6 vdc equipment columns (cabina_antivandalica/adas_presente/mdvr/pantallas/wifi/conexiones_usb/identidad)->general.respuesta_binaria, all single-catalog clean except the two above. Full site-by-view enumeration (selectors vs resolving-joins) still pending.
-
Fix-candidate measurement (SELECT only, no write, GO needed before applying): correct estandar_emisiones_id for the 3 corrupted rows, matched by text per MOVILBA-341 precedent - vdc id 5431 (vehiculo 5072, currently 153/tipo_motor E3) -> candidate 17 (motor.estandar_emisiones EURO3, nombre_mostrable E3). vdc id 4923+4758 (vehiculo 4564/4399, currently 154/tipo_motor E5, same on DEV) -> candidate 59 (motor.estandar_emisiones EURO5, nombre_mostrable E5). Reported to coder03/audit/researcher for GO+fix ownership - two separate actions needed: qualify the join (481's scope) + correct the 3 rows' content (separate write, own GO).
-
Census complete: docs/reference/movilba-481-opciones-view-join-census.md (uncommitted, db lane doesn't commit). 45 views depend on opciones (pg_depend, DEV) = 12 qualified selectors + 14 campo-only selectors (latent, same accident-of-catalog risk noted in rendiciones.ts comments, not impact-measured) + 4 admin/meta (exempt like audit.ts) + 15 with an unqualified resolving JOIN. 18 distinct physical columns behind those 15 views, all measured DEV+PROD: 16 profilactic (zero impact, PK-discriminated like the rest of 308's class), 1 already filed as MOVILBA-482 (P0, live data corruption), 1 new open item - carrocerias.carroceria_aire_acondicionado_id, PROD id=70 resolves against BOTH general.respuesta_binaria(69) and carroceria.aire_acondicionado(1 row) - same UNION-needed shape as clase_licencia_id in 308, pair not established yet, needs a look against the book before assuming which catalog is right (482's own lesson). Full table with counts in the doc. Remaining mechanical work (qualify the 15 views' joins, decide on the 14 selectors) not urgent - all zero-impact except 482/aire_acondicionado.
-
Closed per audit's three calls (05:01): (1) carrocerias.carroceria_aire_acondicionado_id split out as its own P0, filed separately (see linked item) - not folded into 482, different shape (unresolved pair, not corrupted content). (2) The 15 mechanical view-qualify sites batched into one follow-up, zero urgency, sequenced after 482 and the aire_acondicionado item. (3) The 14 campo-only selectors scoped OUT - different class (UI dropdown, no FK, no measured impact), separate ticket if wanted. Census doc: docs/reference/movilba-481-opciones-view-join-census.md.
-
Censo LANDEADO: docs/reference/movilba-481-opciones-view-join-census.md, v5.5.240 (2ec32639). Lo escribio db02 en el checkout COMPARTIDO, que es donde los carriles db dejan los entregables y no commitean; coder03 lo porto al worktree dev y lo shipeo. Correccion menor al texto antes de landear: decia 44 viewdefs en la linea de evidencia contra 45 en el cuerpo. TRES HIJOS ABIERTOS, y el censo se cierra a si mismo: - MOVILBA-482 (P0): 3 filas de PROD con estandar_emisiones_id apuntando al catalogo equivocado. Dato vivo EN PANTALLA. Espera GO de Elazar; nada escrito. - MOVILBA-483 (P1): carrocerias.carroceria_aire_acondicionado_id apunta a dos catalogos vivos, par UNION sin establecer. P1 y no P0 porque db02 midio la provenencia: ningun vehiculo de PROD referencia esa carroceria, denominador CERO, asi que hoy no hay pantalla mostrandolo. - MOVILBA-484 (P3): la cola mecanica - calificar las 15 vistas mas los 14 selectores solo-campo. Los 14 selectores solo-campo SE TRACKEAN, en 484. audit habia dicho de no filarlos y db02 los dejo sin registrar esperando decision: van igual, porque el arreglo es de la misma forma -agregarle el par a una vista-, agruparlos cuesta cero, y un riesgo latente sin item deja de existir cuando se cierra el censo que lo nombraba. VEREDICTO DEL CENSO, con la cobertura dicha: 45 vistas dependientes de opciones por pg_depend en DEV, clasificadas a mano contra pg_get_viewdef porque la forma valida y la invalida usan las mismas palabras. 12 calificadas, 14 selectores solo-campo, 4 admin/meta exentas, 15 con JOIN resolutor sin calificar cubriendo 18 columnas fisicas. De esas 18: 16 con impacto CERO medido en DEV y PROD con control positivo, 1 es 482, 1 es 483. NO EJERCITADO: los 14 selectores solo-campo no se midieron por impacto -no resuelven un FK guardado- y el censo se corrio contra DEV; la poblacion de vistas de PROD no se enumero por separado.