-- Les prestations creees automatiquement quand une reservation arrive.
--
-- UNE REGLE PAR BIEN, ET C'EST LE CHOIX RETENU. Un studio et un chalet n'ont pas les memes
-- besoins : une liste unique valable partout aurait force le meme traitement et laisse
-- corriger a la main, ce qui annule le gain.
--
-- IL N'Y A PAS DE COLONNE « moment », ET C'EST LA SIMPLIFICATION QUI COMPTE.
--
-- On s'attendait a declarer « Menage au depart, Draps a l'arrivee ». Mais le TARIF porte deja
-- son moment — types_prestation.moment, via MomentPrestation — parce que c'est une propriete de
-- la prestation elle-meme et non du bien : un menage se fait au depart chez tout le monde. Le
-- repeter ici creerait deux sources pour une seule verite, avec la question insoluble de savoir
-- laquelle gagne quand elles divergent.
--
-- La regle dit donc seulement QUELLES prestations sont automatiques. L'ecran affiche le moment
-- a cote, en lecture, pour que le concierge sache ce qu'il declenche.

CREATE TABLE bien_automatismes (
    id                 BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    bien_id            BIGINT UNSIGNED NOT NULL,
    type_prestation_id BIGINT UNSIGNED NOT NULL,
    -- La quantite voulue : deux jeux de draps, trois heures de menage. Comme partout, c'est la
    -- quantite qui exprime le nombre, jamais une ligne repetee.
    quantite           SMALLINT UNSIGNED NOT NULL DEFAULT 1,
    cree_le            DATETIME        NOT NULL,
    modifie_le         DATETIME        NOT NULL,
    PRIMARY KEY (id),
    -- Une prestation n'est automatique qu'une fois par bien. La demander deux fois serait une
    -- double saisie, pas un besoin.
    UNIQUE KEY uq_automatisme (bien_id, type_prestation_id),
    -- CASCADE sur le bien : une regle n'a aucun sens sans le logement qu'elle concerne.
    CONSTRAINT fk_automatisme_bien FOREIGN KEY (bien_id)
        REFERENCES biens (id) ON DELETE CASCADE,
    -- CASCADE sur le type aussi : si une prestation quitte le catalogue, la regle qui la
    -- reclame ne peut plus rien produire. La garder ferait echouer chaque synchronisation en
    -- silence — le pire des deux mondes, puisque la synchronisation ne leve jamais.
    CONSTRAINT fk_automatisme_type FOREIGN KEY (type_prestation_id)
        REFERENCES types_prestation (id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- CE QUI N'EST PAS ICI, ET QU'IL FAUT SAVOIR.
--
-- AUCUNE TRACE DE CE QUI A DEJA ETE APPLIQUE. On pourrait craindre de creer deux fois la meme
-- prestation si la synchronisation repasse. Ce n'est pas possible :
-- InterventionRepository::visitePour() est un TROUVE-OU-CREE sur (reservation, moment, date),
-- et intervention_lignes porte un UNIQUE (intervention, type). L'idempotence est donc portee
-- par le schema existant, pas par un journal d'application qu'il faudrait tenir a jour — et
-- qu'on oublierait de purger.
--
-- AUCUN ETAT « suspendu ». Une regle qu'on ne veut plus se supprime : la conserver desactivee
-- ajouterait un troisieme etat a distinguer de l'absence, pour une fonction qui se recoche en
-- un clic.
