Calificar por catalogo 16 vistas con JOIN resolutor sin calificar y 14 selectores solo-campo (re-censo vivo)
Cola mecanica que deja MOVILBA-481 una vez resueltos los dos items de dato vivo (MOVILBA-482 P0 y MOVILBA-483 P1). CERO urgencia: las 15 vistas miden CERO impacto hoy en DEV y PROD, con split de tres y control positivo. El motivo de arreglarlas no es que esten fallando, es que hoy aciertan por una propiedad del catalogo -opciones.id es PK y los catalogos vigentes no chocan- y no por estar calificadas. El dia que un id se re-apunte, la vista muestra una etiqueta ajena sin error y sin NULL. LA LISTA VIVE EN docs/reference/movilba-481-opciones-view-join-census.md (landeado v5.5.240, commit 2ec32639), con el veredicto por columna fisica y las consultas para re-derivar todo. No copiar los numeros de ahi: la pagina misma dice que son de hoy y como volver a medirlos. ALCANCE 1 - las 15 vistas con JOIN resolutor sin calificar: 18 columnas fisicas distintas, deduplicadas porque varias vistas repiten la misma columna. Mecanico UNA VEZ ESTABLECIDO CADA PAR, y establecerlo es la parte que no es mecanica: el par (grupo_nombre, campo_nombre) se verifica contra el catalogo y contra otros usos, NUNCA se adivina del nombre de la columna, y antes hay que mirar contra que pares resuelve DE VERDAD la poblacion - dos de las 18 resultaron ser multi-catalogo y necesitar UNION. ALCANCE 2 - los 14 selectores solo-campo: filtran por campo_nombre sin grupo_nombre. Andan HOY solo porque ningun otro grupo comparte ese campo_nombre, que es un accidente del catalogo y no una invariante. No se midieron por impacto porque no resuelven un FK guardado: son dropdowns de UI, y el modo de falla es una fila nueva de OTRO grupo colandose en una lista. Van aca y no sin registrar, que era la alternativa: el arreglo es de la misma forma -agregarle el par a una vista- y el costo de agruparlos es cero. DDL de vista: pg_depend antes, JAMAS CASCADE, el cuerpo instalado se lee con pg_get_viewdef, y DEV y PROD tienen que quedar iguales.
Activity
-
db02-mba-l-cc / db
-
parent=MOVILBA-481
-
db04-mba-l-ca
-
db04-mba-l-ca 2026-09-24 04:05 -03 — Status sweep limitation: The 15 resolver views and 14 field selectors were not recounted against current installed definitions or exercised with collision controls. BWI show and recent events were read; status unchanged and no DB write.
-
Taking the current installed-definition census and discriminating controls; no DDL until the live pairs/selectors are re-established and reviewed.
-
2026-10-09 current live census (SELECT-only): verified targets first: PROD movilba/elazar/17.6, DEV movilba_dev/movilba_user/15.17. Current pg_depend inventory exposes 45 views referencing public.opciones in each base. Re-derived installed definitions: 16 distinct views currently contain unqualified FK resolver joins (not historical 15); both bases agree on the listed view population/definitions except expected deparser alias/format differences. Fourteen field-only selector views remain the same 14; they cover 10 distinct field names, and each field currently maps to exactly one live grupo_nombre in each base. Fresh stored-FK scan grouped by actual catalog pair found expected pairs for all resolved values; the genuine two-group clase_licencia_id population remains in DEV licencias_choferes (35 personas/clase_licencia + 2 licencia/clase_lnc), requiring UNION semantics. No DDL. Detailed per-column denominator/no-match split and dependency closure remain to finish before any design or implementation.
-
Follow-up live SELECT-only: stored-ID coverage differs by base. All resolved IDs in candidate columns match the intended pair (0 wrong-pair references on both); however DEV personas.tipo_persona_id has 82 non-NULL references, only 79 resolve to opciones and 3 point to absent id=1 (2 on non-deleted personas, 1 deleted). PROD has 36/36 resolved. This is a current label-null data case, not evidence of cross-catalog misresolution, and needs separate classification before describing impact as zero. Direct pg_depend view graph was checked; DEV additionally has agents.v_vehiculo_lookup depending on v_vehiculo_cadena, v_vehiculo_historial and v_vehiculos_detalle (no PROD counterpart), so any future DDL must include that DEV-only dependent in preflight. Query only records catalog-tracked dependencies; it cannot establish absence of runtime SQL consumers/functions. No DDL performed.
-
Per-column denominator table and dependency caveats now recorded in /data-lezama/movilba/evidencia/MOVILBA-484/2026-10-09-opciones-join-census.md; SHA256 ad89c9ee4140d855ad5c2cf4b3893fe9a858f3f29ab8745d0fd678b15c5eea4e. 26 columns: 0 resolved wrong-pair refs in either base; DEV personas.tipo_persona_id has 82 non-NULL, 79 with option row, 3 missing id=1 (2 live, 1 deleted). DEV license class is 35 personas/clase_licencia + 3 licencia/clase_lnc; preserve UNION. Selector set remains 14 views / 10 field names, one current live group per name in both bases. DEV agents.v_vehiculo_lookup depends on v_vehiculo_cadena, v_vehiculo_historial, v_vehiculos_detalle. Report explicitly limits pg_depend and no synthetic collision mutation. No DDL. Next decision: separate the 3 missing-option refs from prophylactic qualification work before proposing a no-CASCADE migration.
-
Follow-up verified the orphan consequence and split: the two non-deleted DEV personas with tipo_persona_id=1 appear in BOTH v_personas_list and v_personas_completas with tipo_persona IS NULL; the third is deleted and excluded. No FK from personas.tipo_persona_id to opciones.id exists in either base. This is a data issue separate from prophylactic view qualification; do not fold repair into 484. Evidence report updated: /data-lezama/movilba/evidencia/MOVILBA-484/2026-10-09-opciones-join-census.md SHA256 c587005f79383e347a2ba149bfcbc11cf953311bf2368919fa673e3afb2c497a. No writes to either DB.
-
Calificar por catalogo 16 vistas con JOIN resolutor sin calificar y 14 selectores solo-campo (re-censo vivo)
-
Backlog cross-check: the orphan tipo_persona_id=1 finding is already in MOVILBA-738's SELECT-only census (7 columns without FK; DEV 3 orphans; 2 live labels NULL); no duplicate item filed and it remains outside this view-only scope. Ran no-write counterfactual selector control on both bases: for each of the 10 fields, adding a synthetic other-group row in a CTE made the exact field-only predicate include it (leak=1), while adding expected group+field excluded it (qualified count unchanged). This tests predicate discrimination, not a mutated installed view. Evidence report final SHA256 b0c6cfc89be75212f7a5596ccaf6740f6c602fb26ca4ade5695c0ab5f2e84fd0. Title corrected to 16 currently installed unqualified-resolver views plus 14 selectors. No DDL.
-
Migration-prep read complete: pinned all 16 candidate view bodies using md5(pg_get_viewdef(oid,true)) plus length; each PROD value equals DEV (table in report), so a paired view-only rewrite can use matched preflight pins. Exact unqualified ON clauses/source columns were re-enumerated in both bases; the class-license pair remains distinct (cl and op aliases) and must keep both catalog arms. SELECT-only synthetic CTE control for 10 selectors discriminates expected field-only leak vs qualified exclusion (not an installed-view mutation). Updated evidence report SHA256 b1328ae9f5474cb13fe866b32eb954fa53008582d2908e566ad25697de7c4bdc. No SQL artifact or DDL drafted yet; next is exact replace design with no-CASCADE dependency/ACL preflight.
-
Completed the owner/ACL/options and direct dependent-view preflight on the 16 current targets. PROD has 13 movilba_owner + 3 postgres owners and explicit relacl on all 16; DEV has movilba_user owner on all 16, relacl NULL on 15 and explicit on v_personas_completas; reloptions NULL throughout. Direct downstream closure is in the evidence report, including DEV-only agents.v_vehiculo_lookup on three targets. Future migration must preserve each base's preimage owner/ACL/options, keep output columns/types ordered, and use no CASCADE; no DDL was executed to test CREATE OR REPLACE behavior. Report SHA256 6fab8d181efac937e8d253667c09ae241d67042365ec61a8979e8bc72baba844.