UUID's (Universeel unieke ID -entifiers) zijn 128-bits waarden die onder andere in databases worden gebruikt om tabelgegevens op unieke wijze te identificeren. Ze worden weergegeven als een hexadecimale reeks verdeeld in vijf groepen gescheiden door koppeltekens (Voorbeeld:: 09fe49b3-4d2b-471c-ac04-36c9e706b85f). Er bestaat talrijk Discussies over de voor- en nadelen van UUID's in databases - ze zijn onmisbaar in gedistribueerde systemen.
In microservices en multi-tenancy toepassingen is het daarom het overwegen waard om UUID's in te voeren. Overschakelen van datatype BigInteger naar UUID (een sorteerbare variant van UUID versie 4 uit de RFC 4122- specificatie) in het PHP-framework Laravel is snel gedaan: eerst maken we een nieuwe eigenschap:
2aa7136d977617159be1834eaf40e871
Dan voegen we al onze modellen toe:
2aa7136d977617159be1834eaf40e871
In Laravel 9⁺ is dit nog eenvoudiger: hier hebben we de eigenschap HasUuids al klaar voor gebruik. Als alternatief biedt het framework ook ondersteuning voor het gerelateerde, maar nog vrij onbekende datatype ULID , wat interessant zou kunnen zijn vanwege een betere leesbaarheid en sorteerbaarheid.
Het lastige is de migratie van bestaande data. Grofweg zou men als volgt te werk kunnen gaan::
- Voeg nieuwe UUID-kolommen met lege waarden toe aan alle tabellen
(elk gebaseerd op alle kolommen met primaire en externe sleutels) - Schrijf UUID-waarden naar de nieuwe kolommen
(met oplopende primaire sleutels plus bijgewerkte externe sleutels) - Oorspronkelijke kolommen verwijderen
- Nieuwe kolommen hernoemen
Er zijn hier verschillende uitdagingen: Het migratieproces duurt lang en nieuwe kolommen worden toegevoegd aan het einde van de tabel (mogelijke oplossing: resortkolommen ). Een veel directere manier is om de kolommen direct te transformeren.
Als je dat stelt PostgreSQL one, kunt u (na een eerdere back-up natuurlijk) bijvoorbeeld de volgende query uitvoeren (daarvoor kunt u alle tabellen verwijderen die u uitsluit in Z. 19/31 vervangen, evenals eigen speciale regels in Z. 37/39 add) en kopieert alle query's die eruit zijn gegenereerd:
2aa7136d977617159be1834eaf40e871
Als je nu de gegenereerde queries samen uitvoert, heb je de database in korte tijd gemigreerd. Hoewel de aldus gegenereerde UUID's niet voldoen aan de v4-specificatie, staan ze lexigrafisch in dezelfde volgorde als de vorige vermeldingen, komen ze niet in botsing met nieuwe UUID's (in de 3e groep in v4 is er altijd een 4, altijd één in de gemigreerde variant 0), wat ook betekent dat nieuwe UUID's altijd groter zijn dan de gemigreerde UUID's.
Daarna wordt aanbevolen om alle Laravel-caches te verwijderen (php artisan cache:clear && php artisan route:clear && php artisan config:clear && php artisan view:clear && composer dump-autoload && rm -rf bootstrap/cache/*/*) en hardloopsessies (rm -f storage/framework/sessions/*) leegmaken. Natuurlijk kan het geheel ook worden geïmplementeerd binnen een Laravel-migratie:
2aa7136d977617159be1834eaf40e871
Na de conversie gebruikt men in plaats daarvan in toekomstige migraties bigIncrements of. bigInteger dan uuid:
2aa7136d977617159be1834eaf40e871