Podar catalogos de especificacion no referenciados: la condicion NO es 'no lo referencia el SSOT vigente'
Orden de Elazar 2026-09-18 (relevada por db02): una fila de catalogo que no referencia nada del SSOT vigente se BORRA FISICO, no se marca. Los agentes las van soft-deleteando, se acumulan como basura, y una fila de catalogo sin uso solo produce errores. Alcanza chasis, carrocerias, fabricantes, motores "or any other option or lookup table". Coincide con el hallazgo de MOVILBA-483 (carroceria id=70 YUTONG sin vehiculos vivos). SALE DE MOVILBA-486 A PROPOSITO. 486 es "materializar el vigente del snapshot en vehiculos/vdc"; la poda de catalogos agrega otra poblacion, otro denominador y otro modo de falla que no comparten nada con eso, y es una escritura de datos de PROD con su propia compuerta. Se mide y se revisa sola, no plegada al ensayo de 486. Acordado con db02 y audit. EL DENOMINADOR EQUIVOCADO, Y ESTA MEDIDO LO QUE CUESTA. "No referenciado por el SSOT vigente" se lee como "no lo referencia la proyeccion". El resolver de carroceria esta MUERTO en PROD: proyecta NULL en el 100% de las filas del snapshot. Entonces la cantidad de filas de public.carrocerias que el historial normalizado no referencia es el CATALOGO ENTERO, mientras que la cantidad que ningun vehiculo vivo referencia es bastante menor. Una regla escrita contra la proyeccion borra las dos poblaciones juntas, incluidas las filas a las que apuntan miles de vehiculos vivos. En public.chasis los dos denominadores tampoco coinciden. Query nombrada: 486_catalogos_no_referenciados en docs/reference/poblaciones-recurrentes.sql. LA CONDICION CORRECTA es la conjuncion, medida contra CADA relacion que referencia el catalogo, enumeradas por pg_depend/FKs y no de memoria: ninguna fila viva de negocio la apunta Y ninguna fila del historial normalizado la apunta. Un catalogo que un resolver roto dejo de referenciar no esta sin usar: esta huerfano de un bug, y borrarlo convierte un defecto reparable en perdida. OPCIONES VA APARTE Y NO ENTRA CON LA MISMA CONSULTA. Es una tabla fisica que contiene muchos catalogos no relacionados. Ahi "cero referencias hoy" NO significa espurio: un valor de enumerado legitimo que todavia nadie eligio tiene cero referencias y es correcto que exista. Encima hay mapeos FIJOS por valor (Unidad_Propulsora, ELECTRICO-CABA) que un borrado por falta de referencias rompe sin tocar ninguna FK. chasis/carrocerias/fabricantes/motores si son filas de especificacion por vehiculo creadas como subproducto del import, y ahi "sin referencias = espuria" se sostiene limpio. CONTROL POSITIVO OBLIGATORIO antes de aceptar la rama: forzarla a NO borrar. Tomar una fila de catalogo referenciada solo por el historial y no por un vehiculo vivo, correr el ensayo, y ver que NO aparece en la poblacion a borrar. Una poda que nunca se vio negarse a borrar es una linea verde. BLOQUEA DE HECHO: arreglar primero el resolver de carroceria, o la medicion de carrocerias no significa nada.
Activity
-
db03 medicion 2026-09-18 05:44 (delegada por db02, SELECT-only DEV+PROD). Denominadores explicitos: opciones total=198 en ambos entornos, misma forma de grupos. sin_fk total: DEV=156, PROD=180 (PERO PROD tiene 2 tablas FK denegadas por permiso -rutap.unidad_propulsora_resolver, rutap.chasis_resolver- asi que 180 es un TECHO, no la cifra real; sin esas dos tablas el grupo motor en PROD ya muestra 2 con_fk menos que DEV en el mismo grupo, senal de que el numero real esta mas cerca de DEV). (1) vistas/funciones: 44 vistas DEV / 45 PROD leen opciones; el patron dominante v_ui_*/v_tipo_*/v_ambito etc filtra por grupo_nombre+campo_nombre SIN valor_opcion literal (expone el menu ENTERO del campo, cero FK es el estado correcto para una opcion sin elegir todavia) - esto es DISTINTO del caso Unidad_Propulsora. El caso de filtro por VALOR LITERAL confirmado esta en v_vehiculos_list_alta/v_vehiculos_list_baja: resuelven grupo='vehiculo'+campo='estado'+valor_opcion='ALTA'/'BAJA' por STRING, no por FK - mismo mecanismo que Unidad_Propulsora, aunque esas dos filas hoy SI tienen FK via estado_id asi que no estan huerfanas todavia. (2) por grupo (total/sin_fk/con_fk), DEV: vehiculo 36/34/2, ubicacion 24/23/1, entidades 16/16/0, contacto 22/16/6, motor 24/15/9, personas 19/11/8, documentos 10/10/0, transporte 11/10/1, licencia 8/6/2, carroceria 6/5/1, general 7/5/2, QA658_grp 2/2/0, validadoras 9/2/7, chofer 2/1/1, vehiculo_historial 2/0/2. PROD: vehiculo 38/36/2, ubicacion 24/23/1, contacto 22/19/3, personas 19/19/0, motor 24/17/7(techo), entidades 16/16/0, transporte 11/11/0, documentos 10/10/0, licencia 8/8/0, validadoras 7/7/0, carroceria 6/5/1, general 7/5/2, QA658_grp 2/2/0, chofer 2/2/0, vehiculo_historial 2/0/2. OJO: PROD tiene MAS grupos al 100% sin_fk que DEV (personas 19/19, validadoras 7/7, licencia 8/8, transporte 11/11) - no es catalogo mas sucio, es MENOS DATO DE NEGOCIO VIVO en PROD en esos dominios (menos choferes/validadoras/licencias con esa opcion elegida), otra prueba de que sin_fk mide poblacion de negocio, no legitimidad del catalogo. (3) grupos con mapeo fijo por valor confirmado via literal en prosrc/viewdef (ademas de motor/Unidad_Propulsora): vehiculo (ALTA/BAJA, PROD suma MAN/MANTENIMIENTO), validadoras (ALTA/BAJA/EMBARCADA/MODIFICACION/OPENPASS/PUESTO_A_TIERRA/SUBE), vehiculo_historial (ALTA/MODIF), ubicacion (AR-C), contacto (MOVIL) - match por substring, riesgo de falso positivo en strings cortos/genericos, no verificado caso por caso. (4) borrado_en no nulo por grupo, DEV: vehiculo 22/36, motor 5/24, entidades 3/16, QA658_grp 2/2, carroceria 2/6, validadoras 2/9, resto 0. PROD: vehiculo 23/38, motor 4/24, entidades 3/16, carroceria 2/6, QA658_grp 2/2, resto 0. VEREDICTO EN UNA LINEA: el conteo por FK NO sirve como criterio unico para opciones - confunde 'nadie eligio esta opcion todavia' y 'menos datos de negocio en este entorno' con 'fila espuria', y es ciego al patron de lookup por valor literal que ya existe en produccion mas alla de Unidad_Propulsora. No se escribio nada, no se propuso lista de borrado ni criterio.
-
Poda EJECUTADA en DEV y PROD (db02), ensayo+apply. opciones/ELECTRICO-CABA: 1 fila borrada fisico por base, id resuelto por contenido no por literal. chasis: 104 DEV / 112 PROD, quedan 32 y 32, cero marcadas. fabricantes (dc46eb19): 1 DEV / 13 PROD, las dos bases terminan en 37 filas y 0 marcadas; el criterio NO es el de chasis sino la conjuncion 'sin refs entrantes Y borrado_en IS NOT NULL', porque el proyector resuelve fabricantes POR VALOR y una fila viva sin FKs sigue siendo destino de resolucion. vivas-sin-refs re-medidas intactas post-DELETE: DEV 7, PROD 6. CONTROL POSITIVO que pedia el item (forzarla a NO borrar) cumplido en chasis: 1 fila por base referenciada SOLO por historial, NO entro a la poblacion. Los triggers de soft-delete se enumeran de pg_trigger y se apagan POR NOMBRE; sin eso el DELETE se vuelve UPDATE de borrado_en y ROW_COUNT informa el numero esperado (le paso a la v1 de chasis ea09a8a9, lo cazo su propio POST en ensayo). QUEDA ABIERTO lo que el item marca como bloqueado: carrocerias NO se poda, por el resolver muerto (MOVILBA-492) y por 15 filas marcadas con 45 vehiculos vivos colgando en PROD (MOVILBA-491). opciones COMO TABLA queda afuera: el criterio por FK marca el 91% de las filas, o sea mide otra cosa; cuando se escriba un criterio para opciones la unidad es el GRUPO, no la tabla. Drift detectado al correrlo: rutap.v_snapshot_catalog_preflight existe en DEV y no en PROD (to_regclass NULL).
-
Poda de catalogos aplicada en DEV y PROD. ELECTRICO-CABA borrado fisico en las dos bases; poda de chasis (DEV 104 / PROD 112); poda de fabricantes (DEV 1 / PROD 13, criterio marcado + cero FK entrantes, migracion 6d80156c). Carrocerias quedo FUERA por resolver muerto -es MOVILBA-492- y opciones quedo fuera porque contar FK ahi es 91% falso positivo. Cerrado por coder03, que lo reporto aplicado en chat.