52 lines
2.6 KiB
SQL
52 lines
2.6 KiB
SQL
-- MijnBesluit - het bonnetje van een samenvoeging
|
|
--
|
|
-- Twee profielen van dezelfde persoon worden er één zodra zij zelf beide uitnodigingen aanneemt.
|
|
-- Tot nu toe was dat onomkeerbaar, en dat stond ook zo in docs/Identiteit.md bij "wat hier nog
|
|
-- niet is opgelost".
|
|
--
|
|
-- Waarom terugdraaien niet zomaar kan: na afloop is niet meer te zien wélke lidmaatschappen,
|
|
-- berichten en bestanden bij het duplicaat hoorden. Ze staan gewoon bij het doel, tussen alles
|
|
-- wat daar al stond. Gokken zou andermans gegevens meesleuren.
|
|
--
|
|
-- Daarom deze tabel. Bij elke samenvoeging komt hier één regel in te staan met precies wat er is
|
|
-- verhuisd, als JSON. Terugdraaien is dan die lijst in omgekeerde volgorde aflopen. Regels die
|
|
-- bij het samenvoegen zijn weggegooid - een dubbel lidmaatschap, een dubbele beheerder - staan
|
|
-- er als volledige kopie in, want die moeten opnieuw worden aangemaakt.
|
|
--
|
|
-- De regel blijft ook na het terugdraaien staan, met undone_at gevuld. Dat er ooit is
|
|
-- samengevoegd is zelf ook geschiedenis.
|
|
--
|
|
-- Let op: samenvoegingen van VOOR deze tabel hebben geen bonnetje en zijn dus niet terug te
|
|
-- draaien. Dat is geen fout die te repareren valt; de gegevens om het mee te doen bestaan niet.
|
|
--
|
|
-- Draaien met:
|
|
-- mysql -u root -p mijnbesluit < db\12_samenvoegingen.sql
|
|
--
|
|
-- Opnieuw draaien mag: er gebeurt dan niets.
|
|
|
|
USE `mijnbesluit`;
|
|
|
|
CREATE TABLE IF NOT EXISTS `samenvoegingen` (
|
|
`id` BIGINT NOT NULL AUTO_INCREMENT,
|
|
`duplicate_person_id` BIGINT NOT NULL,
|
|
`target_person_id` BIGINT NOT NULL,
|
|
`by_user_id` BIGINT NOT NULL,
|
|
`merged_at` DATETIME(6) NOT NULL,
|
|
`steps` LONGTEXT NOT NULL,
|
|
`undone_at` DATETIME(6) NULL,
|
|
`undone_by_user_id` BIGINT NULL,
|
|
`reason` VARCHAR(500) NULL,
|
|
PRIMARY KEY (`id`),
|
|
KEY `ix_samenvoegingen_duplicaat` (`duplicate_person_id`)
|
|
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
|
|
|
|
-- De rechten voor de applicatiegebruiker staan NIET hier maar in 02_applicatiegebruiker.sql.
|
|
--
|
|
-- Waarom: de scripts vanaf 03 worden ook door de uitrolagent gedraaid, met een beperkt
|
|
-- databaseaccount dat geen rechten mág uitdelen. Een GRANT hier laat die hele uitrol struikelen,
|
|
-- en dat account meer macht geven is de verkeerde kant op. Rechten uitdelen is inrichten; dat
|
|
-- doet een mens één keer als root. Een zelfcontrole legt elke CREATE TABLE in deze map naast de
|
|
-- lijst in 02, dus vergeten kan niet ongemerkt.
|
|
|
|
SELECT 'Klaar. Samenvoegingen worden vanaf nu vastgelegd en kunnen worden teruggedraaid.' AS melding;
|