-- =====================================================================
-- backup_schedule pasa a saber a qué contracted_service pertenece
-- Fecha: 2026-08 (aplícalo DESPUÉS de 2026-08_backups_tracking.sql)
--
-- Motivo: antes la relación solo existía en un sentido —
-- contracted_services.backup_schedule_id apuntaba a UN backup_schedule.
-- Revisado y validado también del lado de client_bkps. Se invierte/agrega
-- para que backup_schedule conozca directamente su contracted_service,
-- sin depender del join inverso.
--
-- La columna vieja (contracted_services.backup_schedule_id) NO se toca
-- todavía — se deja para una fase posterior, una vez que nada dependa de
-- ella (ver bloque comentado al final).
-- =====================================================================

-- 1. backup_schedule pasa a saber a qué contracted_service pertenece
ALTER TABLE backup_schedule
  ADD COLUMN contracted_services_id int(11) DEFAULT NULL AFTER BackupScheduleID,
  ADD KEY fk_backup_schedule_contracted_idx (contracted_services_id),
  ADD CONSTRAINT fk_backup_schedule_contracted
    FOREIGN KEY (contracted_services_id) REFERENCES contracted_services (ContractedServicesID) ON UPDATE CASCADE;

-- 2. Backfill: copiar la relación que ya existe antes de que quede huérfana
UPDATE backup_schedule bs
JOIN contracted_services cs ON cs.backup_schedule_id = bs.BackupScheduleID
SET bs.contracted_services_id = cs.ContractedServicesID;

-- 3. (fase posterior, cuando ya nada dependa de la columna vieja)
-- ALTER TABLE contracted_services DROP FOREIGN KEY fk_backup_schedule_id, DROP COLUMN backup_schedule_id;

-- =====================================================================
-- ROLLBACK (comentado)
-- =====================================================================
-- ALTER TABLE backup_schedule
--   DROP FOREIGN KEY fk_backup_schedule_contracted,
--   DROP KEY fk_backup_schedule_contracted_idx,
--   DROP COLUMN contracted_services_id;