-- =====================================================================
-- backup_operations gana velero_namespace
-- Fecha: 2026-08 (aplícalo DESPUÉS de 2026-08_backups_tracking.sql)
--
-- Motivo: inconsistencia de esquema, no una decisión de diseño.
-- Las cuatro tablas de backups guardan dónde debe aplicarse cada fila:
--
--   k8s_context       -> backup_operations, backup_restore, backup_schedule, backup_tracking  (4 de 4)
--   velero_namespace  -> backup_restore, backup_schedule, backup_tracking                      (3 de 4)
--
-- backup_operations es la única con el contexto pero sin el namespace.
-- Se agrega con la misma definición que usan las otras tres
-- (varchar(63) NOT NULL DEFAULT 'velero') para no introducir una cuarta
-- variante.
--
-- Contexto: clnt_bkps_fix corrigió un bug donde el CR de Restore se
-- creaba en el namespace del tenant en vez del de Velero, porque el
-- controller de Velero solo procesa objetos de su propio namespace.
-- El fix hizo que backup_schedule, backup_restore y backup_tracking
-- lean velero_namespace de su propia fila en las tres rutas que ya
-- tenían el dato a mano (provisioning, restore, sync). La única ruta
-- que quedó pendiente es "sincronizar ahora" del portal, que arma su
-- fila desde backup_operations y no podía leer una columna inexistente
-- sin tumbar la consulta completa del loop de operaciones.
--
-- Verificado antes de aplicar (frnt_backups_fix, information_schema +
-- comparación de filas): cero divergencias entre backup_schedule y sus
-- backup_tracking, y entre backup_operations y su backup_schedule. El
-- valor es hoy 'velero' en todos lados por casualidad de default, no
-- por dato copiado -- exactamente la casualidad que este cambio, más el
-- INSERT del portal y el SELECT de client_bkps, terminan de cerrar.
--
-- El default NOT NULL cubre las filas nuevas si el INSERT no llegara a
-- copiar el dato, pero eso dejaría el bug intacto y escondido detrás de
-- la columna -- el INSERT de "sincronizar ahora" (frnt_backups_fix) debe
-- copiar velero_namespace del backup_schedule/backup_restore al que
-- apunta la operación, igual que hace el backfill de abajo para las
-- filas existentes.
-- =====================================================================

ALTER TABLE `backup_operations`
  ADD COLUMN `velero_namespace` varchar(63) NOT NULL DEFAULT 'velero' AFTER `k8s_context`;

-- Backfill: copiar el namespace real de la fila a la que apunta cada
-- operación existente, en vez de confiar en el default.
UPDATE `backup_operations` bo
JOIN `backup_schedule` bs ON bs.`BackupScheduleID` = bo.`backup_schedule_id`
SET bo.`velero_namespace` = bs.`velero_namespace`
WHERE bo.`backup_schedule_id` IS NOT NULL;

UPDATE `backup_operations` bo
JOIN `backup_restore` br ON br.`BackupRestoreID` = bo.`backup_restore_id`
SET bo.`velero_namespace` = br.`velero_namespace`
WHERE bo.`backup_restore_id` IS NOT NULL;

-- Verificación (no debería haber filas fuera de 'velero' salvo que el
-- cluster tenga Velero en otro namespace)
-- SELECT velero_namespace, COUNT(*) FROM backup_operations GROUP BY velero_namespace;

-- =====================================================================
-- ROLLBACK (comentado)
-- =====================================================================
-- ALTER TABLE `backup_operations` DROP COLUMN `velero_namespace`;