-- ================================================================================
-- LE CATALOGUE APPARTIENT A LA CONCIERGERIE, PLUS AU CONCIERGE
-- ================================================================================
--
-- CE QUI EXISTAIT, ET POURQUOI C'ETAIT UNE ERREUR DE CONCEPTION.
--
-- « types_prestation.concierge_id » pointait vers « utilisateurs.id ». Une prestation
-- appartenait donc a un COMPTE, et deux comptes concierge de la meme entreprise avaient deux
-- catalogues disjoints : le salarie ne voyait pas les prestations du gerant et devait les
-- ressaisir. L'entreprise se comportait comme deux entreprises.
--
-- Le savoir-faire appartient a la societe, pas a l'employe. Un depart de salarie ne doit pas
-- emporter le catalogue.
--
-- LA COLONNE EXISTAIT DEJA POUR LE DIRE. « utilisateurs.conciergerie_id » rattache un compte a
-- son entreprise depuis la migration 034 ; « types_prestation » l'ignorait simplement. Ce n'est
-- donc pas un modele qu'on etend, c'est un rattachement qu'on branche sur celui qui existe.
--
-- ================================================================================
-- CE QUI N'EST PAS TOUCHE ICI, ET C'EST DELIBERE
-- ================================================================================
--
-- « biens.concierge_id » reste un compte. Un logement est suivi par QUELQU'UN — c'est lui qu'on
-- appelle, c'est son planning qui se remplit — alors qu'une prestation est une capacite de
-- l'entreprise. Les deux rattachements ne disent pas la meme chose et n'ont pas a bouger
-- ensemble.
--
-- La consequence est assumee : les tarifs se resolvent desormais en DEUX sauts — le bien donne
-- son concierge, le concierge donne sa conciergerie, la conciergerie donne le catalogue.

-- ================================================================================
-- EN TROIS TEMPS, ET LE TROISIEME EST UN GARDE-FOU
-- ================================================================================
--
-- On ajoute NULLABLE, on remplit, puis on rend obligatoire. Le detour n'est pas une precaution
-- de facade : c'est le troisieme temps qui protege.
--
-- UN CONCIERGE SANS CONCIERGERIE PRODUIRAIT UN NULL. Le « MODIFY ... NOT NULL » ECHOUE alors,
-- bruyamment, et la migration s'arrete avant d'avoir rien detruit. C'est exactement ce qu'on
-- veut : plutot qu'un catalogue silencieusement rattache a une entreprise arbitraire, ou des
-- lignes supprimees sans que personne l'ait demande, la reprise s'interrompt et se regarde.
--
-- Verifie avant ecriture sur la base locale : « types_prestation » et « tarifs » sont VIDES, et
-- aucun concierge n'est sans conciergerie. Ce chemin ne deplace donc aucune donnee aujourd'hui.
-- Il est ecrit juste quand meme, parce qu'une migration se rejoue ailleurs que sur la base ou
-- on l'a ecrite.

ALTER TABLE types_prestation
    ADD COLUMN conciergerie_id BIGINT UNSIGNED NULL AFTER reference;

UPDATE types_prestation t
  JOIN utilisateurs u ON u.id = t.concierge_id
   SET t.conciergerie_id = u.conciergerie_id;

ALTER TABLE types_prestation
    MODIFY COLUMN conciergerie_id BIGINT UNSIGNED NOT NULL;

-- ================================================================================
-- L'ANCIEN RATTACHEMENT S'EN VA EN ENTIER
-- ================================================================================
--
-- La contrainte AVANT la colonne : MariaDB refuse de supprimer une colonne encore portee par
-- une cle etrangere. Et l'unicite avant elle aussi — « uq_types_prestation_libelle » etait
-- posee sur (concierge_id, libelle).
--
-- ON NE GARDE PAS « concierge_id » « au cas ou ». Une colonne que plus rien n'ecrit et que
-- quelque chose lit encore est le pire des deux mondes : elle se fige a sa derniere valeur et
-- ment sans erreur. Le depot n'a pas de donnee de production, c'est le moment de trancher net.

ALTER TABLE types_prestation
    DROP FOREIGN KEY fk_types_prestation_concierge;

ALTER TABLE types_prestation
    DROP INDEX uq_types_prestation_libelle,
    DROP INDEX idx_types_prestation_concierge,
    DROP COLUMN concierge_id;

-- ================================================================================
-- LE NOUVEAU RATTACHEMENT, AVEC LES MEMES GARANTIES
-- ================================================================================
--
-- L'UNICITE DU LIBELLE EST MAINTENANT A L'ECHELLE DE L'ENTREPRISE, et c'est tout l'objet de la
-- migration : « Menage » ne peut plus exister deux fois dans la meme conciergerie, meme saisi
-- par deux personnes differentes. C'est precisement le doublon que l'ancien modele fabriquait.
--
-- L'INDEX DE LECTURE SUIT LA REQUETE DU CATALOGUE : (conciergerie_id, actif, ordre) est l'ordre
-- exact du WHERE puis du ORDER BY. Un index sur la seule conciergerie aurait laisse le tri se
-- faire en memoire.
--
-- RESTRICT IMPLICITE, comme avant : on ne supprime pas une conciergerie, on la desactive. Si
-- une suppression finissait par arriver, elle doit echouer plutot que d'emporter le catalogue
-- et, par cascade, les tarifs qui s'y accrochent.

ALTER TABLE types_prestation
    ADD UNIQUE KEY uq_types_prestation_libelle (conciergerie_id, libelle),
    ADD KEY idx_types_prestation_conciergerie (conciergerie_id, actif, ordre),
    ADD CONSTRAINT fk_types_prestation_conciergerie
        FOREIGN KEY (conciergerie_id) REFERENCES conciergeries (id);
