-- Une intervention se rattache a une reservation, obligatoirement.
--
-- C'est le coeur du changement de modele. Une prestation ne se demande plus « pour un
-- bien a une date » mais « pour un sejour » : c'est le sejour qui la motive, qui donne
-- sa date, et dont l'annulation la remet en cause.
--
-- NOT NULL, donc, et c'est un choix explicite. Un lien optionnel aurait laisse coexister
-- deux especes d'interventions avec deux comportements — celles qu'une annulation remet
-- en cause et les autres — pour une economie de raisonnement nulle. La contrepartie est
-- reelle et assumee : un bien sans flux iCal n'a aucune reservation, donc rien de
-- demandable, tant que la saisie manuelle d'une reservation n'existe pas. Elle arrive
-- avec cette iteration.
--
-- RESTRICT sur la cle etrangere, et non CASCADE. Supprimer une reservation ne doit pas
-- effacer le travail qui en decoulait : c'est de l'historique, parfois deja facture. De
-- toute facon plus rien ne supprime une reservation depuis la migration 016 — une
-- annulation la marque.
--
-- bien_id RESTE sur interventions, alors que la reservation le porte deja. C'est une
-- redondance volontaire : bien_id est l'axe de TOUTES les clauses de portee
-- (PorteeBiens), et les faire passer par une jointure sur reservations alourdirait
-- chaque lecture pour rien. Le prix a payer est une regle a tenir : l'application ecrit
-- toujours les deux depuis la meme reservation. Aucune contrainte SQL ne peut le
-- garantir — un CHECK ne sait pas interroger une autre table.

-- Les interventions existantes sont effacees. Il n'y a pas d'alternative honnete :
-- aucune ne porte de reservation, et il n'existe aucun moyen de deviner laquelle —
-- rapprocher par bien et par date reviendrait a inventer un rattachement, ce qui est
-- pire qu'une table vide. A cette date, la fonction vient d'etre livree et l'ecran des
-- prestations etait encore en erreur : ces lignes sont des essais.
DELETE FROM interventions;

ALTER TABLE interventions
    ADD COLUMN reservation_id BIGINT UNSIGNED NOT NULL AFTER bien_id,

    -- Laquelle des deux occurrences cette intervention represente. « Draps » sur un
    -- sejour en produit deux : une a l'arrivee, une au depart. Sans cette colonne, elles
    -- seraient indistinguables et l'unicite ci-dessous refuserait la seconde.
    ADD COLUMN moment ENUM('arrivee','depart','libre') NOT NULL DEFAULT 'libre'
        AFTER type_prestation_id,

    -- Pourquoi cette intervention est repassee a confirmer, quand c'est le cas. NULL =
    -- rien a signaler. Le concierge doit pouvoir lire la cause : une intervention qui
    -- redevient « a valider » sans explication ressemble a un defaut du logiciel.
    ADD COLUMN alerte ENUM('reservation_annulee','reservation_deplacee') NULL
        AFTER modification,

    -- Une seule demande par sejour, par prestation et par moment. Deux « menage au
    -- depart » sur le meme sejour seraient une double saisie, pas un besoin : la
    -- quantite est deja portee par la colonne quantite.
    ADD UNIQUE KEY uq_interventions_reservation_prestation
        (reservation_id, type_prestation_id, moment),

    -- Sert la liste sous le calendrier : les prestations d'une reservation.
    ADD KEY idx_interventions_reservation (reservation_id, date_prevue),

    ADD CONSTRAINT fk_interventions_reservation
        FOREIGN KEY (reservation_id) REFERENCES reservations (id);
