soft-delete de vehiculo no cascadea a vehiculo_historial
Salio del MEMORY.md global el 2026-08-20 durante la poda que pidio Elazar (el indice de memoria no es un backlog). Soft-deletear un vehiculo deja sus filas de vehiculo_historial vivas, asi que el historial sobrevive a su vehiculo. Contexto obligatorio antes de proponer nada: mem:reference_baja_is_a_state_not_a_deletion (la baja es un ESTADO, y DISABLE TRIGGER + DELETE sobre vehiculo_historial se RECHAZA aun con GO) y mem:reference_borrado_en_holds_rutap_fecha_baja_not_a_deletion (2309 filas de vehiculo_historial guardan la Fecha Baja de RUTAP en borrado_en, o sea que borrado_en NO significa borrado ahi). Por eso agregar el cascade NO es la respuesta obvia: puede depender de MOVILBA-83 y de la decision de MOVILBA-42. Medir primero, proponer despues.
Activity
-
CHANGED, y el mecanismo del titulo esta mal. Medido por db-mba-l-cc 2026-08-21 08:14. Prod: 658 vehiculos soft-deleteados y tienen CERO filas de vehiculo_historial - no cero vivas, cero filas. Nada sobrevive a su vehiculo en prod. Dev: 680 soft-deleteados, 2 de ellos con 2 filas de historial vivas. PERO prod no esta limpio por un cascade: fn_cascade_soft_delete_vehiculo cascadea vehiculos -> vehiculos_datos_colectivos solamente y nunca toca vehiculo_historial. O sea que prod esta limpio por como se construyeron sus datos, no por una guarda, y el hueco es real y sin proteger en los DOS entornos - solo que tiene 0 instancias en prod y 2 en dev. Segun la instruccion del propio item, sigue siendo decision de MODELO detras de 42/83 y no un cascade para agregar.
-
Applied and verified DEV+PROD 2026-08-26. fn_cascade_soft_delete_vehiculo now also closes the active vehiculo_historial row (borrado_en/borrado_por) when a vehiculo is soft-deleted. Migration: docs/migrations/2026-08-26-movilba91-cascade-vehiculo-historial-{DEV,PROD}.sql. Verified functionally in a rolled-back txn (1 open historial row -> 0 after cascade) and independently confirmed by audit-mba-l-cc post-PROD-apply.