-- ================================================================================
-- UNE NOTIFICATION DIT CE QUE QUELQU'UN A FAIT
-- ================================================================================
--
-- CE QUI MANQUAIT. « notifications » portait l'evenement, le sujet, le titre, le detail et le
-- lien — mais pas l'AUTEUR. Le fil pouvait donc dire « Prestation terminee : Menage complet »
-- sans jamais dire par qui. L'information existait a cote, dans
-- « intervention_evenements.acteur_id », et la rattacher apres coup demandait de deviner quel
-- evenement correspondait a quelle notification. Deviner, sur une trace, n'est pas acceptable.
--
-- ================================================================================
-- LA COLONNE EST NULLABLE, ET C'EST LE POINT IMPORTANT
-- ================================================================================
--
-- J'avais annonce NOT NULL, puisque la table est videe et qu'aucune ligne heritee ne resterait
-- sans auteur. C'ETAIT FAUX, et pour une raison de fond : DEUX EVENEMENTS SUR TREIZE N'ONT PAS
-- D'AUTEUR HUMAIN.
--
-- « sejour_deplace » et « sejour_annule » sont ecrits par le rapprochement iCal — le flux d'un
-- calendrier Airbnb ou Booking. Personne ne les provoque. Notificateur en tient deja compte, et
-- son commentaire le dit : « un acteur NULL n'est pas soi-meme, donc personne n'est exclu » ;
-- sans cela, ces deux alertes — les plus couteuses a rater — n'auraient atteint personne.
--
-- IMPOSER NOT NULL AURAIT DONC FORCE UNE VALEUR FAUSSE. Il n'y a que deux facons de remplir une
-- colonne obligatoire quand l'auteur n'existe pas : mettre le destinataire, qui devient alors
-- l'auteur d'un evenement qu'il subit, ou mettre un compte technique, qui n'existe pas dans ce
-- projet. Les deux mentent, et l'ecran les afficherait.
--
-- NULL VEUT DIRE « PERSONNE », PAS « ON NE SAIT PAS ». C'est une valeur pleine de sens ici : le
-- fil dira « le calendrier a change » plutot que d'attribuer le geste a quelqu'un.

-- ================================================================================
-- LE FIL EST VIDE AVANT LA REPRISE
-- ================================================================================
--
-- Demande explicitement, et cela simplifie la suite : aucune ligne ancienne a rattacher a un
-- auteur qu'on ne connait plus. Les notifications sont par nature perissables — un fil se lit
-- dans les jours qui suivent, jamais des mois apres — donc rien d'historique ne se perd. Le
-- journal d'audit et « intervention_evenements », eux, gardent tout : c'est la que vit la trace.
--
-- DELETE ET NON TRUNCATE : la table est referencee par une cle etrangere, et TRUNCATE la refuse
-- des qu'une contrainte pointe vers elle. DELETE fonctionne toujours et se journalise — sur
-- quelques dizaines de lignes, la difference de vitesse n'existe pas.

DELETE FROM notifications;

ALTER TABLE notifications
    ADD COLUMN acteur_id BIGINT UNSIGNED NULL AFTER destinataire_id;

-- ================================================================================
-- RESTRICT IMPLICITE, COMME PARTOUT DANS CE SCHEMA
-- ================================================================================
--
-- On ne supprime pas un compte, on le revoque. Si une suppression finissait par arriver, elle
-- doit echouer plutot que d'emporter les notifications qui nomment cette personne — ou, pire, de
-- les laisser pointer vers un identifiant qui n'existe plus.
--
-- PAS D'INDEX SUR acteur_id. On ne cherche jamais « les notifications ecrites par untel » : le
-- fil se lit toujours par destinataire. Un index qui ne sert aucune requete coute a chaque
-- ecriture et ne rend rien.

ALTER TABLE notifications
    ADD CONSTRAINT fk_notifications_acteur
        FOREIGN KEY (acteur_id) REFERENCES utilisateurs (id);
