Las 15 vistas envoltorio de soft-delete: paquete firmado, ensayado en dev y prod y auditado, pero SIN GO, SIN ejecutor asignado (db02 se retiro) y sin consumidor identificado - es el unico del dia que AGREGA superficie en vez de corregir algo
PAQUETE ESCRITO, ENSAYADO EN LOS DOS ENTORNOS, AUDITADO Y SIN APLICAR. Es el unico paquete firmado del dia que quedo sin GO; los otros cuatro (115, 111, 112, 109-D) ya estan aplicados. DEV: docs/migrations/2026-08-21-soft-delete-base-views-DEV.sql md5 91fce71ef028033b6c6c339fe20a1bee PROD: docs/migrations/2026-08-21-soft-delete-base-views-PROD.sql md5 a729e4298964d51e42116a5c87374083 Autor db02-mba-l-cc (carril RETIRADO por Elazar el 08-21 11:27 - la ejecucion queda sin dueno, ver abajo). Los dos archivos estan committeados y limpios en sus hashes firmados. QUE HACE. Genera dinamicamente, sobre una lista FIJA de 15 nombres, un envoltorio por cada TABLA BASE: CREATE OR REPLACE VIEW public.v_<tabla> AS SELECT * FROM public.<tabla> WHERE borrado_en IS NULL O sea: crea vistas nuevas que filtran las filas borradas logicamente. NO modifica ninguna vista existente - verificado por db-mba-l-cc y db02-mba-l-cc por separado al descartar el acople con la opcion D: `v_vehiculos_export` aparece CERO veces en los dos archivos. PARA QUE SIRVE, que es lo que hay que decidir si todavia se quiere. El problema de fondo es que hoy el codigo puede joinear contra la tabla base y traerse filas borradas sin darse cuenta - la baja es un ESTADO y las filas quedan. Un envoltorio por tabla da un camino unico y sancionado que ya viene filtrado, para que el proximo join no tenga que acordarse. Es prevencion, no un bug abierto: nadie reporto un sintoma que esto arregle. POR QUE SIGUE PARADO Y NO ES UN OLVIDO. Tres cosas, ninguna resuelta: 1. NO HAY GO. Nunca se pidio uno describiendolo; el GO del 08-21 nombro 111, 112 y 109d, y un GO cubre lo DESCRITO. 2. NO TIENE EJECUTOR. db02-mba-l-cc lo escribio y se retiro. El superusuario de prod lo tiene ahora db03-mba-l-ca, asi que la ejecucion es posible, pero nadie la tiene asignada. 3. CREA 15 OBJETOS NUEVOS EN PROD, que es la unica cosa del dia que AGREGA superficie en vez de corregir algo existente. Cada vista nueva es un objeto mas que mantener, y si despues nadie la consume queda como peso muerto - el mismo patron que dejo medio db-map.md apuntando a funciones que ya no existen. LO QUE HAY QUE RE-MEDIR ANTES DE PEDIR EL GO, no se puede heredar de ayer: que las 15 tablas sigan existiendo y sigan teniendo borrado_en; que no exista ya una vista con ese nombre (el CREATE OR REPLACE la pisaria en silencio); y sobre todo QUIEN VA A CONSUMIRLAS - un envoltorio sin consumidor es superficie sin beneficio. Ademas, bajo la regla nueva de gates de entorno, los dos archivos deberian llevar `inet_server_addr()` junto a `current_database()`: el NOMBRE de la base no es unico en el parque de GCABA y `movilba_dev` no vive en el mismo host que `movilba`. DECIDIR: (a) aplicar como esta, previa re-medicion y con un ejecutor asignado; (b) recortar la lista a las tablas que hoy tienen un consumidor real; (c) descartarlo y borrar los dos archivos, dejando la deuda documentada. Ninguna es urgente y ninguna arregla un sintoma vivo.
Activity
-
PARKED (PM decision 2026-08-26 06:04): audit-mba-l-cc reconfirmed zero consumers in src/ for all 15 wrapper views - no app code references any v_<table> name. No GO given, not applied. Not deleted either - files stay as a signed, tested, ready-to-apply artifact if a consumer ever appears. If picked up later, close the gate gap first (checks current_database() only, not inet_server_addr - db_name isn't unique across GCABA's fleet).
-
coder-mba-l-ca / coder
-
Reassigned from offline coder-mba-l-cc. Owner: coder-mba-l-ca (decision + consumer inventory). Re-measure before any GO per author's note - 15 tables/borrado_en, no name collision, WHO CONSUMES check. Execution/re-measurement partner: db03-mba-l-ca. No GO exists yet - none was requested describing this ticket. Recommend option (b): cut list to tables with a named consumer today.
-
Consumer inventory: zero exact references in src to any of the 15 proposed v_<table> wrapper names. Existing app reads/writes base tables directly, so no consumer can be switched by merely applying the wrappers. Recommendation remains option (b), which currently yields an empty apply set; retain signed scripts deferred until a named read consumer is designed. DB03 re-measurement requested before any GO/action.
-
unassigned
-
db03-mba-l-cc
-
db04-mba-l-ca
-
researcher-mba-l-cc / solo
-
2026-10-08T12:47:28-03:00 researcher-mba-l-cc re-measurement. Count discrepancy: the signed package (docs/migrations/2026-08-21-soft-delete-base-views-{DEV,PROD}.sql) lists exactly 13 target tables in _soft_delete_view_targets, not the "15" the ticket title/body claim: carrocerias, chasis, licencias_choferes, linea_entidad_asignaciones, lineas_transporte, paradas, recorridos, regimen_servicio, regimen_servicio_modalidad, vehiculos, vehiculos_datos_colectivos, vehiculos_subtipos_transporte, vehiculos_tipos_transporte. Both DEV and PROD files carry the identical 13-item list. No trace of the other 2 anywhere in either file. Gate would abort today: one of the 13 targets, lineas_transporte, was already physically dropped this session (MOVILBA-668, done). The package's own per-table DO $$ block raises `gate: public.% is not a base table with borrado_en` whenever the target doesn't exist, inside one transaction covering all 13 CREATE OR REPLACE VIEW statements. Run unmodified against either base today, it aborts on that iteration before creating any of the 13 views - the signed/rehearsed state no longer matches current schema. Consumer search: grepped all 13 view names (v_carrocerias, v_chasis, v_licencias_choferes, v_linea_entidad_asignaciones, v_lineas_transporte, v_paradas, v_recorridos, v_regimen_servicio, v_regimen_servicio_modalidad, v_vehiculos, v_vehiculos_datos_colectivos, v_vehiculos_subtipos_transporte, v_vehiculos_tipos_transporte) across src/, tools/, api-external/, docs/reference/parque-movil-api/. Zero real consumers. The one apparent hit (v_vehiculos, 7 files under api-external/php-api/ and tools/aiql-movilba/CLAUDE.md) is a false positive from an unanchored grep: those matches are all "dev_vehiculos" (a MariaDB table in the external PHP sync API, 6 files) or a same-named but unrelated MariaDB view in api-external/php-api/external-api-db.yaml:115 (`FROM vehiculos_rutap`, that API's own schema) - neither is PostgreSQL public.v_vehiculos. No file in the repo or the external trees queries the actual wrapper view. Recommendation: discard. Zero consumers for all 13 names, the list itself no longer matches the live schema (12 of 13 tables remain, one gone), and the ticket's own "15" premise doesn't match the file contents either - three independent reasons the package isn't ready to apply as-is, and nothing identifies who would consume it if trimmed and re-signed. Per the standing rule that an option no code path uses is not a decision for Elazar: closing this as discard, not escalating the apply/trim choice.
-
coder03 2026-10-08 13:02 ART: discarded on researcher's measurement, no consumer so my call per the standing rule. The signed package lists 13 tables, not the 15 the title claims, and lineas_transporte among them was already dropped this session (MOVILBA-668), so the package would abort on its own gate if run unmodified. Zero real consumers for all 13 names; the one apparent v_vehiculos hit was dev_vehiculos, an unrelated MariaDB view in the external PHP API, not public.v_vehiculos. A package that only ADDS surface with no consumer does not ship.