Decidir alcance retroactivo de la regla de columnas de auditoría — cifras 2026-08-21 obsoletas, pendiente remedir creado_en y borrado_en
LA REGLA YA ESTA DICTADA Y NO SE DISCUTE. Elazar, 2026-08-21, fleet-wide: creado_en, creado_por, borrado_en, borrado_por, modificado_en, modificado_por y toda columna equivalente de auditoria o soft-delete son SOLO para rastro de auditoria y borrado logico. Las escriben UNICAMENTE triggers y/o codigo de auditoria - nunca escrituras de logica de negocio, backfills ni correcciones manuales. La logica de app PUEDE leerlas para saber cuando se creo/modifico/borro una FILA y por quien; NO DEBE leerlas para saber cuando ocurrio un EVENTO DE NEGOCIO. Toda fecha de negocio vive en columnas que no son de auditoria. LO QUE FALTA DECIDIR ES EL ALCANCE HACIA ATRAS, y es una sola pregunta: la regla gobierna solo las ESCRITURAS FUTURAS, o tambien obliga a reparar los valores YA GUARDADOS que la violan? Nadie puede contestarla por Elazar porque cambia el tamano del trabajo de una linea de codigo a una migracion de datos sobre miles de filas. SE PARTE EN DOS CASOS Y LA RESPUESTA PUEDE SER DISTINTA PARA CADA UNO - esto es lo que hace que no sea una pregunta sino dos: CASO A - creado_en, 2441 de 4052 filas de vehiculo_historial. Guardan fecha_alta a medianoche: una fecha de NEGOCIO metida en una columna de AUDITORIA. Es la violacion en su forma pura. Es BACKFILLEABLE: fecha_alta existe como columna propia y tiene el dato, asi que se puede reparar creado_en al instante real de insercion sin inventar nada... salvo que ese instante real ya se perdio, y ahi la reparacion honesta es NULL o el instante de la migracion, no una fecha fabricada. Ver MOVILBA-113: 8 consumidores leen creado_en como recencia y la columna corre al REVES del orden de insercion, asi que el dano no es teorico. CASO B - borrado_en, 2314 de 2315 filas. NO es backfilleable y no por falta de dato: esas marcas son cierres que el indice unico uq_vehiculo_historial_activo FUERZA estructuralmente para liberar el slot vivo de la proxima alta. No son borrados que haya hecho nadie. Repararlas exigiria primero cambiar el modelo (MOVILBA-42), porque hoy la columna carga DOS significados y solo uno es auditoria. Corolario medido: por eso ninguna de las 2315 tiene borrado_por - no hubo actor. Ver MOVILBA-118. TRES RESPUESTAS POSIBLES, y conviene que Elazar pueda contestar distinto por caso: 1. SOLO ESCRITURAS FUTURAS. Los valores guardados quedan como estan y se documentan como deuda conocida. Barato, honesto, y deja a los 8 consumidores de 113 leyendo una columna que miente. 2. RETROACTIVA DONDE HAY VERDAD RECUPERABLE. Se repara el caso A y el B se declara bloqueado por 42. Es la unica que se puede ejecutar hoy sin cambiar el modelo. 3. RETROACTIVA TOTAL. Exige 42 primero. No es un item, es una secuencia. REGLA DE ORO QUE NO SE PUEDE ROMPER EN NINGUNA DE LAS TRES: nunca se INVENTA un valor de auditoria. Si el instante real se perdio, la reparacion es dejarlo NULL o marcarlo, jamas fabricar una fecha o un autor plausibles - fabricar dato de auditoria es peor que el hueco, que es exactamente el razonamiento por el que MOVILBA-118 NO backfillea borrado_por. Contraste util: estado_id de MOVILBA-117 SI es columna de negocio y por eso ese backfill si es legitimo. BLOQUEA: MOVILBA-113 (que arreglar y si se toca el dato guardado), y define el orden de MOVILBA-42/118. No bloquea nada que ya este en prod.
Activity
-
db02-mba-l-cc / db
-
db04-mba-l-ca
-
db04-mba-l-ca 2026-09-24 04:05 -03 — Status sweep limitation: The requested Elazar decision on retroactive audit-column repair is not recorded in this sweep; current stored-value damage and consumer impacts were not recomputed. BWI show and recent events were read; status unchanged and no DB write.
-
db04-mba-l-ca 2026-09-24 04:13 -03 — Elazar must decide whether the 2026-08-21 audit-column rule applies only to future writes, retroactively where the true audit value is recoverable, or retroactively after the history model changes; he may answer separately for creado_en and borrado_en. No agent may invent a historical audit timestamp or author. The historical 2441/2314 denominators were not recomputed against the replacement schema in this sweep. No DB write.
-
Decidir alcance retroactivo de la regla de columnas de auditoría — cifras 2026-08-21 obsoletas, pendiente remedir creado_en y borrado_en
-
db04-mba-l-ca 2026-10-01 21:29 ART — La decisión de Elazar sigue pendiente: sólo escrituras futuras, o corrección retroactiva separada para creado_en y borrado_en. Las cifras 2441/4052 y 2314/2315 son una medición de 2026-08-21 sobre el esquema anterior; NO se recalcularon contra el esquema de reemplazo y no deben usarse para dimensionar ni decidir una migración actual. El título ahora las marca obsoletas. Próximo paso antes de una decisión basada en tamaño: remedir ambas poblaciones en PROD y DEV con el esquema instalado; no inventar fechas ni autores de auditoría. Sin escritura de DB.
-
db03-mba-l-cc 2026-10-05 15:05 ART - REMEASURE on the installed schema, SELECT only, PROD then DEV. public.vehiculo_historial no longer exists (to_regclass NULL in both); the replacement is rutap.vehiculo_historial_normalizado. Unique indexes: pkey + vh_norm_raw_key(rutap_snapshot_id, rutap_fila_excel). uq_vehiculo_historial_activo is GONE, so case B's 'structurally forced closures' premise no longer exists. PROD movilba: total 5548. CASE A creado_en = fecha_alta::timestamp: 0; creado_en at midnight (any): 0; creado_en NULL: 0; creado_por = system_import 5548/5548. CASE B borrado_en NOT NULL: 0 (of those, borrado_por NULL: 0); borrado_por without borrado_en: 0. Positive control: fecha_baja NOT NULL = 3946, so the business baja date lives in its own column and borrado_en is not overloaded. DEV movilba_dev: total 5686. Case A 0, midnight 0, creado_en NULL 0; case B borrado_en NOT NULL 0; fecha_baja NOT NULL 4028. creado_por: system_import 5548 + 138 app rows (68/35/21/7/... user ids). VERDICT: both violating populations are 0 in both bases. Option B (retroactive fill of only what can be proven) has nothing to repair; the rule reduces to option A (future writes only), which the installed schema already satisfies for this table. Proposal: close 121 as resolved by the schema replacement, without an Elazar decision; MOVILBA-83 (same borrado_en overload premise) closes with it. NOT MEASURED: audit columns on other tables (public.vehiculos, vdc, catalogs); triggers or code that write creado_en going forward; MOVILBA-113's 8 consumers.
-
cleared: db04-mba-l-ca 2026-10-01 21:29 ART — La decisión de Elazar sigue pendiente: sólo escrituras futuras, o corrección retroactiva separada para creado_en y borrado_en. Las cifras 2441/4052 y 2314/2315 son una medición de 2026-08-21 sobre el esquema anterior; NO se recalcularon contra el esquema de reemplazo y no deben usarse para dimensionar ni decidir una migración actual. El título ahora las marca obsoletas. Próximo paso antes de una decisión basada en tamaño: remedir ambas poblaciones en PROD y DEV con el esquema instalado; no inventar fechas ni autores de auditoría. Sin escritura de DB.
-
db03-mba-l-cc 2026-10-05 15:06 ART - CLOSED per coder03. Measured on the installed schema (SELECT only, PROD then DEV): public.vehiculo_historial is gone; on rutap.vehiculo_historial_normalizado, creado_en = fecha_alta midnight is 0/5548 PROD and 0/5686 DEV; borrado_en NOT NULL is 0 in both bases; the baja date lives in fecha_baja (3946 PROD / 4028 DEV); uq_vehiculo_historial_activo no longer exists. Nothing stored violates the audit-column rule, so the retroactive-scope question is moot. NOT MEASURED: audit columns on other tables; future writers of creado_en.