-- L'envoi des alertes par courriel : ce qu'il faut en plus dans le fil.
--
-- AUCUNE TABLE DE FILE N'EST CREEE, ET C'EST LE POINT DE CETTE MIGRATION.
--
-- On avait annonce « une table notifications, plus une file d'envoi ». La seconde n'existe
-- pas : les lignes de notifications qui portent alerte = 1 et courriel_le IS NULL SONT la
-- file. Une table separee aurait duplique le destinataire, le texte et le sujet, avec la
-- derive que toute duplication finit par produire — un courriel envoye dont le fil ne garde
-- pas trace, ou l'inverse.
--
-- CONSEQUENCE HEUREUSE : la question « le client a-t-il ete prevenu ? » a UNE reponse, au
-- meme endroit que l'information elle-meme.

ALTER TABLE notifications
    -- LE NOMBRE DE TENTATIVES, sans quoi un incident passager devient une perte definitive.
    --
    -- Sans ce compteur il n'y a que deux etats possibles : « pas encore envoye » et « en
    -- echec ». Le premier fait reessayer indefiniment un courriel qui ne partira jamais —
    -- adresse morte, quota depasse — et le second abandonne des le premier 502 du relais.
    -- Aucun des deux n'est acceptable : les alertes sont precisement ce qu'on ne veut ni
    -- perdre, ni envoyer cent fois.
    ADD COLUMN courriel_essais TINYINT UNSIGNED NOT NULL DEFAULT 0 AFTER courriel_erreur,

    -- L'INDEX QUI PORTE LA LECTURE DU CRON, et il compte : cette requete tournera toutes
    -- les cinq minutes sur une table qui ne fait que grossir. Sans lui, chaque passage
    -- parcourrait l'integralite du fil pour n'y trouver, la plupart du temps, rien.
    --
    -- L'ordre des colonnes suit celui du WHERE : alerte d'abord (elle elimine la majorite
    -- des lignes, le fil portant plus d'informations que d'alertes), puis courriel_le, puis
    -- le compteur d'essais.
    ADD KEY idx_notif_a_envoyer (alerte, courriel_le, courriel_essais);
