Syftet med denna artikel är att med hjälp av biblioteket schema-keeper visa verktyg som avsevärt underlättar utvecklingsprocessen för databaser inom PHP-projekt som använder databashanteringssystemet PostgreSQL.

Informationen i denna artikel kommer framförallt vara till nytta för utvecklare som vill maximera användningen av PostgreSQL:s förmågor, men som stöter på problem med att hantera affärslogik som ligger i databasen.

Artikeln kommer inte att beskriva fördelarna eller nackdelarna med att lagra affärslogik i databasen. Det förutsätts att valet redan är gjort av läsaren.

Följande frågor kommer att behandlas:

I vilket format man ska lagra en dump av databasens struktur i versionskontrollsystemet (VCS)
Hur man spårar förändringar i databasens struktur efter att dumpen har sparats
Hur man överför ändringar i databasens struktur till andra miljöer utan konflikter och stora migreringsfiler
Hur man organiserar processen för parallellt arbete på projektet för flera utvecklare
Hur man säkert deployar flera ändringar i databasens struktur till produktionsmiljön
SchemaKeeper är inriktad på att arbeta med lagrade procedurer skrivna på språket PL/pgSQL. Testning med andra språk har inte genomförts, vilket innebär att användningen kan vara mindre effektiv eller till och med omöjlig.

I vilket format man ska lagra en dump av databasens struktur i VCS

Bibliotek schema-keeper erbjuder funktionen saveDump, som sparar strukturen av alla objekt från databasen som separata textfiler. En katalog skapas som innehåller databassstrukturen, uppdelad i grupperade filer som enkelt kan läggas till i VCS.

Låt oss titta på konversionen av objekt från databasen till filer med några exempel:

Objekttyp
Diagram
Namn
Relativ sökväg till filen

Tabell
public
accounts
./public/tables/accounts.txt

Lagrad procedur
public
auth(hash bigint)
./public/functions/auth(int8).sql

Representation
booking
tariffs
./booking/views/tariffs.txt

Innehållet i filerna är en textrepresentation av strukturen för ett specifikt databask objekt. Till exempel, för lagrade procedurer kommer innehållet i filen att vara den fullständiga definitionen av den lagrade proceduren, som börjar med blocket CREATE OR REPLACE FUNCTION.

Som framgår av tabellen ovan innehåller filens sökväg information om typ, schema och namn på objektet. Detta tillvägagångssätt underlättar navigering genom dumpen och granskning av kodändringar i databasen.

Utvidgning .sql För filer med källkod för lagrade procedurer valdes för att IDE automatiskt ska kunna tillhandahålla verktyg för databaskommunikation när filen öppnas.

Hur man spårar förändringar i databasens struktur efter att dumpen har sparats

Genom att spara en dump av den aktuella databasstrukturen i VCS får vi möjlighet att kontrollera om det har gjorts ändringar i strukturen efter att dumpen skapades. I biblioteket schema-keeper för att identifiera ändringar i databasstrukturen finns en funktion verifyDump, som utan biverkningar returnerar information om skillnader.

Ett alternativt sätt att kontrollera — anropa igen funktionen saveDump, ange samma katalog och kontrollera i VCS om det finns ändringar. Eftersom alla objekt från databasen har sparats i separata filer, kommer VCS att visa endast de ändrade objekten.
Den största nackdelen med detta sätt är behovet av att skriva över filer för att se ändringar.

Hur man överför ändringar i databasens struktur till andra miljöer utan konflikter och stora migreringsfiler

Tack vare funktionen deployDump källkoden för lagrade procedurer kan redigeras precis som vanlig källkod för applikationen. Man kan lägga till/ta bort rader i koden för lagrade procedurer och omedelbart skicka ändringarna till versionskontrollsystemet, eller skapa/ta bort lagrade procedurer genom att skapa/ta bort motsvarande filer i dump-katalogen.

Till exempel, för att skapa en ny lagrad procedur i schemat public räcker det med att skapa en ny fil med ändelsen .sql i katalogen public/functions, placera koden för den lagrade proceduren i den, inklusive blocket CREATE OR REPLACE FUNCTION, och sedan anropa funktionen deployDump. Samma sak gäller för att ändra och ta bort lagrade procedurer. På så sätt hamnar koden både i VCS och i databasen.

Om det uppstår ett fel i koden för någon lagrad procedur, eller en oenighet mellan filens namn och den lagrade proceduren, kommer deployDump inte att utföras och visa felmeddelandet. Oenighet mellan lagrade procedurer mellan dumpen och den aktuella databasen är inte möjligt när man använder deployDump.

Vid skapandet av en ny lagrad procedur behöver man inte manuellt ange det korrekta filnamnet. Det räcker med att filen har ändelsen .sql. Efter anropet kommer felmeddelandet att innehålla det korrekta namnet som kan användas för att döpa om filen. deployDump gör att man kan ändra funktionsparametrar eller returtyp utan ytterligare åtgärder, medan man i den klassiska metoden skulle ha

deployDump först behöva göra
DROP FUNCTION , och först därefter, а только потом CREATE OR REPLACE FUNCTION.

Tyvärr finns det situationer när deployDump ändringar inte kan tillämpas automatiskt. Till exempel om en triggerfunktion tas bort som används av åtminstone en trigger. Sådana situationer hanteras manuellt med hjälp av migrationsfiler.

Om ansvarar för att flytta ändringar i lagrade procedurer schema-keeper, så krävs migrationsfiler för att överföra övriga strukturella ändringar. Ett bra bibliotek för migrationsarbete är doctrine/migrations.

Migrationer måste tillämpas innan deployDump. Det gör att alla strukturella ändringar kan göras och problematiska situationer kan lösas så att ändringarna i lagrade procedurer kan överföras utan problem.

Arbetet med migrationer kommer att beskrivas mer ingående i följande avsnitt.

Hur man organiserar processen för parallellt arbete på projektet för flera utvecklare

Ett skript för fullständig DB-initialisering måste skapas, som utvecklaren kommer att köra på sin arbetsmaskin för att anpassa den lokala DB-strukturen till den som sparats i VCS-dumpen. Det enklaste är att dela upp initialiseringen av den lokala DB:n i tre steg:

Importera filen med den grundläggande strukturen, som kan kallas base.sql
Tillämpa migrationer
Anrop deployDump

base.sql — detta är utgångspunkten där migrationer tillämpas och en deployDump, det vill säga base.sql + migrationer + deployDump = aktuell DB-struktur. En sådan fil kan skapas med hjälp av ett verktyg pg_dump. Används base.sql endast vid initialisering av databasen från grunden.

Låt oss kalla skriptet för fullständig DB-initiering refresh.sh. Arbetsflödet kan se ut på följande sätt:

Utvecklaren kör refresh.sh i sin miljö och får den aktuella DB-strukturen
Utvecklaren börjar arbeta med den tilldelade uppgiften, och modifierar den lokala DB:n för att passa de nya funktionernas behov (ALTER TABLE ... ADD COLUMN och så vidare)
Efter att uppgiften är slutförd kallar utvecklaren på funktionen saveDump, för att spara de ändringar som gjorts i DB i VCS
Utvecklaren kör refresh.sh, sedan verifyDumpigen, som nu visar en lista över ändringar som ska inkluderas i migrationen
Utvecklaren flyttar alla strukturella ändringar till migrationsfilen, kör refresh.sh och verifyDumpigen, och om migrationen har sammanställts korrekt, verifyDump kommer den att visa att det inte finns några skillnader mellan den lokala DB:n och den sparade dumpen.

Processen som beskrivs ovan är kompatibel med gitflow-principerna. Varje gren i VCS kommer att innehålla sin version av dumpen, och vid sammanslagning av grenar kommer dumpor att slås samman. I de flesta fall behöver inga ytterligare åtgärder vidtas efter sammanslagningen, men om ändringar har gjorts i olika grenar, till exempel i samma tabell, kan det uppstå en konflikt.

Låt oss överväga en konfliktfull situation som exempel: det finns en gren develop, från vilken två grenar har avvikit: feature1 och feature2, som inte har konflikter med develop, men har konflikter mellan sig. Uppgiften är att utföra en sammanslagning av båda grenarna i develop. För detta fall rekommenderas det att först utföra sammanslagningen av en av grenarna till develop, och sedan sammanslagningen develop till den återstående grenen, och lösa konflikterna i den återstående grenen, varefter den sista grenen slås samman i develop. I konfliktlösningssteget kan det vara nödvändigt att justera migrationsfilen i den sista grenen så att den motsvarar den slutgiltiga dumpen, som inkluderar resultaten från sammanslagningarna.

Hur man säkert deployar flera ändringar i databasens struktur till produktionsmiljön

Genom att ha en dump av den aktuella databasen i VCS finns möjligheten att kontrollera produktionsdatabasen mot den krävs strukturen. Detta garanterar att alla förändringar som utvecklarna avsett har överförts till produktionsdatabasen.

Eftersom DDL i PostgreSQL är transaktionell, det rekommenderas att följa följande distribueringsordning, så att, i händelse av oförutsedd fel, göra det "smärtfritt". ROLLBACK:

Starta transaktionen
Utför alla migrationer inom transaktionen
Utför deployDump
utan att avsluta transaktionen. Om inga fel finns, utför verifyDump. Om det finns fel, utför COMMITDessa steg kan lätt integreras i befintliga distributionsmetoder för applikationer, inklusive zero-downtime. ROLLBACK

Genom de metoder som beskrivits ovan kan man pressa maximalt med prestanda ur "PHP + PostgreSQL"-projekt, medan man offrar en relativt liten mängd av utvecklingsbekvämlighet jämfört med att implementera hela affärslogiken i huvudapplikationen. Dessutom verkar databehandlingen i

Slutsats

ofta mer transparent och kräver mindre kod än samma funktionalitet skriven i PHP. PL/pgSQL Syftet med denna artikel är att med hjälp av biblioteket schema-keeper visa verktyg som gör det möjligt att avsevärt.

Källa: habr.com