-- Sources iCal et reservations.
--
-- Deux tables parce que ce sont deux choses : une source est un abonnement
-- durable (l'URL du calendrier Airbnb d'un bien), une reservation est un
-- evenement date. Un bien peut avoir plusieurs sources — Airbnb, Booking, Abritel
-- — et le planning les superpose.
--
-- Import a sens unique : on lit les flux des plateformes, on ne leur ecrit rien.
-- Et l'import est fait par le cron, pas a l'affichage : aller chercher trois URL
-- distantes a chaque chargement de page rendrait le planning lent et dependant de
-- la disponibilite d'Airbnb.

CREATE TABLE sources_ical (
    id               BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    reference        CHAR(26)        NOT NULL,
    bien_id          BIGINT UNSIGNED NOT NULL,
    libelle          VARCHAR(60)     NOT NULL,

    -- 1000 caracteres : les URL iCal des plateformes portent des jetons longs.
    -- VARCHAR(255) tronquerait silencieusement et l'import echouerait sans que
    -- l'on comprenne pourquoi.
    url              VARCHAR(1000)   NOT NULL,

    actif            TINYINT(1)      NOT NULL DEFAULT 1,
    derniere_sync_le DATETIME        NULL,

    -- Compte rendu de la derniere tentative, succes comme echec. Sans cela, une
    -- source qui ne repond plus depuis trois semaines passe inapercue : le
    -- planning se contente d'etre incomplet, ce qui ne se voit pas.
    dernier_resultat VARCHAR(190)    NULL,
    derniere_reussite_le DATETIME    NULL,

    cree_le          DATETIME        NOT NULL,
    modifie_le       DATETIME        NOT NULL,

    PRIMARY KEY (id),
    UNIQUE KEY uq_sources_ical_reference (reference),
    KEY idx_sources_ical_bien (bien_id, actif),

    CONSTRAINT fk_sources_ical_bien
        FOREIGN KEY (bien_id) REFERENCES biens (id) ON DELETE CASCADE
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_unicode_ci;

-- Les reservations.
--
-- fin est la date de DEPART, exclusive, comme dans la norme iCal : un sejour du 3
-- au 5 occupe les nuits du 3 et du 4, et le bien est libre le 5. C'est la
-- convention des plateformes, et s'en ecarter decalerait tout d'un jour.
--
-- uid vient du flux et identifie l'evenement chez la plateforme. L'unicite par
-- (source, uid) est ce qui rend l'import idempotent : resynchroniser met a jour au
-- lieu de dupliquer.
--
-- source_ical_id nullable, pour les reservations saisies a la main — hors sujet
-- pour cette iteration, mais la colonne evite une migration le jour ou elles
-- arriveront.

CREATE TABLE reservations (
    id             BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    bien_id        BIGINT UNSIGNED NOT NULL,
    source_ical_id BIGINT UNSIGNED NULL,
    uid            VARCHAR(190)    NOT NULL,
    debut          DATE            NOT NULL,
    fin            DATE            NOT NULL,
    resume         VARCHAR(190)    NULL,
    cree_le        DATETIME        NOT NULL,
    modifie_le     DATETIME        NOT NULL,

    PRIMARY KEY (id),
    UNIQUE KEY uq_reservations_source_uid (source_ical_id, uid),

    -- Index de la requete du planning : les reservations d'un bien sur une
    -- fenetre de dates.
    KEY idx_reservations_bien_dates (bien_id, debut, fin),

    CONSTRAINT fk_reservations_bien
        FOREIGN KEY (bien_id) REFERENCES biens (id) ON DELETE CASCADE,
    CONSTRAINT fk_reservations_source
        FOREIGN KEY (source_ical_id) REFERENCES sources_ical (id) ON DELETE CASCADE
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
