-- Les reservations acquierent une identite publique et un cycle de vie.
--
-- POURQUOI CETTE MIGRATION EXISTE. Le modele change : une intervention se rattache
-- desormais a une reservation. Deux obstacles s'y opposaient.
--
-- 1. L'IDENTITE N'ETAIT PAS STABLE. PlanningRepository::remplacerReservations()
--    effacait toutes les reservations d'une source puis les reinserait a chaque
--    synchronisation. reservations.id changeait donc toutes les heures, au passage du
--    cron. Une cle etrangere depuis interventions aurait ete detruite a chaque fois :
--    en CASCADE elle supprimait les interventions, en SET NULL elle les orphelinait,
--    en RESTRICT elle faisait echouer l'import. La colonne uid existait deja, avec son
--    unicite par (source, uid) — elle n'etait simplement pas exploitee. La
--    synchronisation passe au RAPPROCHEMENT : mise a jour par uid, et rien n'est
--    supprime.
--
-- 2. UNE ANNULATION SUPPRIMAIT LA LIGNE. C'etait le compromis assume par la migration
--    012 : effacer et reinserer etait « le seul moyen simple de faire disparaitre une
--    reservation annulee ». Avec un rattachement obligatoire, supprimer la reservation
--    arracherait son ancrage a l'intervention. Une reservation disparue du flux est
--    donc MARQUEE annulee et conservee : le concierge doit voir pourquoi son
--    intervention est repassee a confirmer, et la date du sejour annule fait partie de
--    l'explication.
--
-- reference : un ULID, comme partout ailleurs, parce qu'une reservation devient
-- adressable — on demande une prestation POUR une reservation, donc son identifiant
-- circule dans les URL. Un id auto-incremente y exposerait le volume et se devinerait.

-- Les reservations existantes sont effacees, et c'est sans perte : elles ne sont
-- qu'un cache des flux iCal, que la prochaine synchronisation reconstruira a
-- l'identique. Il n'y a de toute facon pas d'autre voie — un ULID se genere en PHP,
-- pas en SQL, donc aucune valeur ne pourrait etre donnee aux lignes existantes pour
-- satisfaire la contrainte d'unicite. La saisie manuelle, seule donnee qui serait
-- irremplacable, n'existe pas encore a cette date.
DELETE FROM reservations;

ALTER TABLE reservations
    ADD COLUMN reference CHAR(26) NOT NULL AFTER id,

    -- Le cycle de vie d'une reservation, vu de l'application. « annulee » signifie
    -- « a disparu du flux de la plateforme », ce qui est la seule facon dont une
    -- annulation nous parvient : les plateformes ne publient pas d'evenement
    -- d'annulation, l'evenement cesse simplement d'etre la.
    ADD COLUMN statut ENUM('active','annulee') NOT NULL DEFAULT 'active' AFTER resume,
    ADD COLUMN annulee_le DATETIME NULL AFTER statut,

    ADD UNIQUE KEY uq_reservations_reference (reference),

    -- La liste sous le calendrier lit les reservations d'un bien par date, en ecartant
    -- les annulees : le statut fait donc partie de l'index.
    ADD KEY idx_reservations_bien_statut (bien_id, statut, debut);
