UUID'er (Universelt unikke id -enifikatorer) er 128-bit værdier, der blandt andet bruges i databaser til entydigt at identificere tabelposter. De er repræsenteret som en hexadecimal streng opdelt i fem grupper adskilt af bindestreger (eksempel: 09fe49b3-4d2b-471c-ac04-36c9e706b85f
). Der er talrige Diskussioner om fordele og ulemper ved UUID'er i databaser - de er uundværlige i distribuerede systemer.
I mikrotjenester og multi-tenancy-applikationer er det derfor værd at overveje at indføre UUID'er. Skift fra datatype BigInteger til UUID (en sorterbar variant af UUID version 4 fra RFC 4122 -specifikationen) i PHP-rammeværket Laravel sker hurtigt: Først opretter vi en ny egenskab:
2aa7136d977617159be1834eaf40e871
Så tilføjer vi alle vores modeller:
2aa7136d977617159be1834eaf40e871
I Laravel 9⁺ er dette endnu nemmere: her har vi allerede HasUuids- egenskaben klar til brug. Alternativt tilbyder rammeværket også understøttelse af den relaterede, men stadig ret ukendte datatype ULID , som kunne være interessant på grund af bedre læsbarhed og sorterbarhed.
Den svære del er migreringen af eksisterende data. Man kunne groft sagt gå frem som følger:
- Tilføj nye UUID-kolonner med tomme værdier til alle tabeller
(hver baseret på alle primære og fremmede nøglekolonner) - Skriv UUID-værdier til de nye kolonner
(med stigende primære nøgler plus opdaterede fremmednøgler) - Slet originale kolonner
- Omdøb nye kolonner
Der er flere udfordringer her: Migreringsprocessen tager lang tid, og nye kolonner tilføjes i slutningen af tabellen (mulig løsning: udvejskolonner ). En meget mere direkte måde er at transformere kolonnerne direkte.
Hvis du sætter det PostgreSQL for det første kan du (efter en tidligere backup, selvfølgelig) køre følgende forespørgsel, for eksempel (før det kan du slette alle tabeller, som du udelukker i Z. 19
/31
erstatte, samt egne særregler i Z. 37
/39
add) og kopierer alle forespørgsler genereret fra den:
2aa7136d977617159be1834eaf40e871
Hvis du nu kører de genererede forespørgsler sammen, har du migreret databasen inden for kort tid. Mens de således genererede UUID'er ikke er i overensstemmelse med v4-specifikationen, er de leksigrafisk i samme rækkefølge som de tidligere poster, kolliderer ikke med nye UUID'er (i den 3. gruppe i v4 er der altid en 4
, altid en i den migrerede variant 0
), hvilket også betyder, at nye UUID'er altid er større end de migrerede UUID'er.
Derefter anbefales det at slette alle Laravel-caches (php artisan cache:clear && php artisan route:clear && php artisan config:clear && php artisan view:clear && composer dump-autoload && rm -rf bootstrap/cache/*/*
) og løbesessioner (rm -f storage/framework/sessions/*
) at tømme. Det hele kan selvfølgelig også implementeres inden for en Laravel-migrering:
2aa7136d977617159be1834eaf40e871
Efter konverteringen bruger man i stedet for fremtidige migreringer bigIncrements
eller. bigInteger
derefter uuid
:
2aa7136d977617159be1834eaf40e871