-- LE BIEN SE RATTACHE A UN CONCIERGE ET A UN CLIENT, plus a des comptes utilisateur.
--
-- Deux tables d'association disparaissent, et chacune pour une raison differente.
--
-- bien_proprietaire liait un bien a des COMPTES. Le lien exact est « ce bien appartient a
-- ce client », et le client peut avoir trois comptes ou aucun. Passer par les comptes
-- rendait le second cas impossible a representer.
--
-- bien_prestataire n'aurait jamais du exister. Un prestataire n'est pas rattache a des
-- logements : on lui confie des interventions. Sa portee se lit donc sur ce qui lui est
-- ASSIGNE, ce qui est a la fois plus juste et plus restrictif — il ne decouvre l'adresse
-- et le code de boite a cles que des logements ou il doit effectivement se rendre.

ALTER TABLE biens
    -- NULL possible, et il faut l'assumer : les biens existants n'ont pas de client, et
    -- l'application doit les montrer comme tels plutot que de les cacher. Un bien sans
    -- client reste visible de son concierge, qui est justement celui qui doit le rattacher.
    ADD COLUMN client_id    BIGINT UNSIGNED NULL AFTER reference,
    ADD COLUMN concierge_id BIGINT UNSIGNED NULL AFTER client_id,
    ADD KEY idx_biens_client (client_id),
    ADD KEY idx_biens_concierge (concierge_id);

ALTER TABLE biens
    ADD CONSTRAINT fk_biens_client FOREIGN KEY (client_id)
        REFERENCES clients (id) ON DELETE SET NULL;

ALTER TABLE biens
    ADD CONSTRAINT fk_biens_concierge FOREIGN KEY (concierge_id)
        REFERENCES utilisateurs (id) ON DELETE SET NULL;

-- LE CONCIERGE EST REPRIS DE L'ANCIEN CHEMIN, avant que celui-ci ne disparaisse.
--
-- Jusqu'ici, « les biens de ce concierge » se lisait en passant par ses proprietaires :
-- bien_proprietaire, puis utilisateurs.concierge_id. On fige ici le resultat de ce calcul
-- dans une colonne, ce qui donne exactement le meme perimetre qu'avant la migration. Sans
-- cette reprise, chaque concierge perdrait la totalite de ses biens.
--
-- MIN() parce qu'un bien detenu par deux proprietaires rattaches a deux concierges
-- differents devait choisir : l'ancien modele le rendait visible des deux, le nouveau
-- exige un rattachement unique. Le cas est marginal, et le concierge restant peut
-- reattribuer le bien depuis sa fiche.
UPDATE biens b
   SET b.concierge_id = (
       SELECT MIN(p.concierge_id)
         FROM bien_proprietaire bp
         JOIN utilisateurs p ON p.id = bp.utilisateur_id
        WHERE bp.bien_id = b.id AND p.concierge_id IS NOT NULL
   )
 WHERE b.concierge_id IS NULL;

-- Un bien cree par un concierge et jamais rattache a un proprietaire : on lui donne son
-- createur. Sans cela il deviendrait invisible de tous, y compris de celui qui l'a saisi.
UPDATE biens b
   JOIN utilisateurs u ON u.id = b.cree_par AND u.role = 'concierge'
    SET b.concierge_id = u.id
 WHERE b.concierge_id IS NULL;

-- Les clients, eux, ne sont PAS reconstitues : la base ne peut pas deviner qu'un bien
-- detenu par Monsieur et Madame releve d'un seul foyer. Ils se saisissent depuis l'ecran
-- Clients, et les biens s'y rattachent ensuite.
DROP TABLE bien_prestataire;

DROP TABLE bien_proprietaire;
