Målet med denne artikel er at vise værktøjer, der væsentligt kan lette udviklingsprocessen af databaser i PHP-projekter, der bruger PostgreSQL, med hjælp fra biblioteket schema-keeper . Informationen fra denne artikel vil primært være nyttig for udviklere, der ønsker at maksimere brugen af PostgreSQL, men som står over for problemer med vedligeholdelsen af forretningslogik, der er flyttet til databasen.

Artiklen vil ikke beskrive fordele eller ulemper ved at opbevare forretningslogik i databasen. Det antages, at læseren allerede har truffet et valg.

Der vil blive overvejet følgende emner:

Hvordan skal man gemme en dump af databasens struktur i versionskontrolsystemet (herefter kaldet VCS)

Hvordan kan man spore ændringer i databasens struktur efter gemme dumpen
Hvordan kan man overføre ændringer i databasens struktur til andre miljøer uden konflikter og enorme migrationsfiler
Hvordan kan man sikre en parallel arbejdsproces for flere udviklere på projektet
Hvordan kan man sikkert deploye et større antal ændringer i databasens struktur til produktionsmiljøet
SchemaKeeper
er designet til at arbejde med lagrede procedurer skrevet i PL/pgSQL . Testning med andre sprog er ikke foretaget, så brugen kan muligvis ikke være så effektiv eller umulig.Hvordan skal man gemme en dump af databasens struktur i VCS

giver funktionen

Bibliotek schema-keeper saveDump , som gemmer strukturen af alle objekter fra databasen som separate tekstfiler. Outputtet er et bibliotek, der indeholder databasens struktur opdelt i grupperede filer, som let kan tilføjes til VCS.Lad os se på transformationsprocessen af objekter fra databasen til filer med flere eksempler:

Objekttype

Relativ sti til filen
Diagram
Navn
Tabel

accounts
public
./public/tables/accounts.txt
Lagret procedure

auth(hash bigint)
public
./public/functions/auth(int8).sql
Visning

booking
tariffs
./booking/views/tariffs.txt
Indholdet af filerne er en tekstlig repræsentation af strukturen for det specifikke databaseobjekt. For eksempel vil indholdet af filen for lagrede procedurer være den fuldstændige definition, der starter med blokken

CREATE OR REPLACE FUNCTION Som det fremgår af tabellen ovenfor, indeholder stien til filen information om typen, skemaet og navnet på objektet. Denne tilgang letter navigeringen i dumpet og code review af ændringer i databasen..

Udvidelse

.sql .sql For files with the source code of stored procedures, it is selected so that the IDE automatically provides tools for interacting with the database when opening the file.

Hvordan kan man overføre ændringer i databasens struktur til andre miljøer uden konflikter og enorme migrationsfiler

By saving a dump of the current database structure in VCS, we gain the ability to check whether any changes were made to the structure of the database after the dump was created. In the library schema-keeper to identify changes in the database structure, there is a function verifyDump, which returns information about the differences without side effects.

An alternative way to check is to call the function again, specifying the same directory, and check for changes in VCS. Since all objects from the database are saved in separate files, VCS will only show the changed objects. , som gemmer strukturen af alle objekter fra databasen som separate tekstfiler. Outputtet er et bibliotek, der indeholder databasens struktur opdelt i grupperede filer, som let kan tilføjes til VCS.deployDump
The main downside of this method is the need to overwrite files in order to see changes.

Hvordan kan man sikre en parallel arbejdsproces for flere udviklere på projektet

Takket være funktionen The source code of stored procedures can be modified just like regular application source code. You can add/remove new lines in the stored procedure code and immediately commit changes to the version control system, or create/delete stored procedures by creating/deleting the corresponding files in the dump directory. For example, to create a new stored procedure in the schema

, it is sufficient to create a new file with the extension public in the directory .sql public/functions , place the source code of the stored procedure in it, including the block, and then call the function Som det fremgår af tabellen ovenfor, indeholder stien til filen information om typen, skemaet og navnet på objektet. Denne tilgang letter navigeringen i dumpet og code review af ændringer i databasen.. Similarly, modification and deletion of stored procedures occur. Thus, the code is simultaneously sent to both VCS and the database. The source code of stored procedures can be modified just like regular application source code. You can add/remove new lines in the stored procedure code and immediately commit changes to the version control system, or create/delete stored procedures by creating/deleting the corresponding files in the dump directory.If there is an error in the source code of any stored procedure, or a mismatch between the file name and the stored procedure name, then

will not execute, displaying the error message. Mismatches of stored procedures between the dump and the current database are not possible when using The source code of stored procedures can be modified just like regular application source code. You can add/remove new lines in the stored procedure code and immediately commit changes to the version control system, or create/delete stored procedures by creating/deleting the corresponding files in the dump directory. When creating a new stored procedure, there is no need to manually enter the correct file name. It is enough for the file to have the extension The source code of stored procedures can be modified just like regular application source code. You can add/remove new lines in the stored procedure code and immediately commit changes to the version control system, or create/delete stored procedures by creating/deleting the corresponding files in the dump directory..

. After calling .sql, the error message will contain the correct name that can be used to rename the file. The source code of stored procedures can be modified just like regular application source code. You can add/remove new lines in the stored procedure code and immediately commit changes to the version control system, or create/delete stored procedures by creating/deleting the corresponding files in the dump directory. allows changing the function parameters or return type without additional actions, whereas with the classical approach, one would first have to

The source code of stored procedures can be modified just like regular application source code. You can add/remove new lines in the stored procedure code and immediately commit changes to the version control system, or create/delete stored procedures by creating/deleting the corresponding files in the dump directory. execute
DROP FUNCTION , and only then., og først derefter Som det fremgår af tabellen ovenfor, indeholder stien til filen information om typen, skemaet og navnet på objektet. Denne tilgang letter navigeringen i dumpet og code review af ændringer i databasen..

Desværre er der nogle situationer, hvor The source code of stored procedures can be modified just like regular application source code. You can add/remove new lines in the stored procedure code and immediately commit changes to the version control system, or create/delete stored procedures by creating/deleting the corresponding files in the dump directory. ændringer ikke kan anvendes automatisk. For eksempel, hvis en triggerfunktion, der bruges af mindst én trigger, slettes. Sådanne situationer håndteres manuelt med migrationsfiler.

Hvis flytningen af ændringerne i de gemte procedurer varetages af selve schema-keeper, skal der bruges migrationsfiler til at overføre de øvrige ændringer i strukturen. For eksempel er et godt bibliotek til at arbejde med migrationer doctrine/migrations.

Migrationer skal anvendes inden The source code of stored procedures can be modified just like regular application source code. You can add/remove new lines in the stored procedure code and immediately commit changes to the version control system, or create/delete stored procedures by creating/deleting the corresponding files in the dump directory.. Dette gør det muligt at foretage alle ændringer i strukturen og løse problematiske situationer, så ændringerne i de gemte procedurer kan flyttes uden problemer senere.

Arbejdet med migrationer vil blive beskrevet nærmere i de følgende afsnit.

Hvordan kan man sikkert deploye et større antal ændringer i databasens struktur til produktionsmiljøet

Det er nødvendigt at oprette et script til fuld initialisering af databasen, som vil blive kørt af udvikleren på sin arbejdsstation, hvilket bringer strukturen af den lokale database i overensstemmelse med det gemte dump i VCS. Det er nemmest at opdele initialiseringen af den lokale database i 3 trin:

Import af en fil med den grundlæggende struktur, som for eksempel vil blive kaldt base.sql
Anvendelse af migrationer
Kald The source code of stored procedures can be modified just like regular application source code. You can add/remove new lines in the stored procedure code and immediately commit changes to the version control system, or create/delete stored procedures by creating/deleting the corresponding files in the dump directory.

base.sql — dette er udgangspunktet, som migrationerne anvendes oven på, og det udføres The source code of stored procedures can be modified just like regular application source code. You can add/remove new lines in the stored procedure code and immediately commit changes to the version control system, or create/delete stored procedures by creating/deleting the corresponding files in the dump directory., altså base.sql + migrationer + deployDump = aktuel database struktur. En sådan fil kan dannes ved hjælp af værktøjet pg_dump. Det bruges base.sql udelukkende ved initialisering af databasen fra bunden.

Lad os kalde scriptet til fuld initialisering af databasen refresh.sh. Arbejdsprocessen kan se således ud:

Udvikleren kører i sit miljø refresh.sh og får den aktuelle database struktur
Udvikleren begynder at arbejde på den tildelte opgave, idet han tilpasser den lokale database til behovene for den nye funktionalitet (ALTER TABLE ... ADD COLUMN osv.)
Efter opgavens afslutning kalder udvikleren funktionen , som gemmer strukturen af alle objekter fra databasen som separate tekstfiler. Outputtet er et bibliotek, der indeholder databasens struktur opdelt i grupperede filer, som let kan tilføjes til VCS., for at registrere ændringerne, der er foretaget i databasen, i VCS
Udvikleren kører igen refresh.sh, og derefter verifyDump, som nu viser en liste over ændringer, der skal inkluderes i migrationen
Udvikleren overfører alle strukturændringer til migrationsfilen, kører igen refresh.sh og verifyDump, og hvis migrationen er sammensat korrekt, verifyDump vil den vise, at der ikke er nogen forskelle mellem den lokale database og det gemte dump.

Den beskrevne proces er kompatibel med gitflow-principperne. Hver gren i VCS vil indeholde sin version af dumpet, og når grene flettes, vil dumpene også blive flettet. I de fleste tilfælde kræves der ikke yderligere handlinger efter fletningen, men hvis der er blevet foretaget ændringer i forskellige grene, for eksempel i den samme tabel, kan der opstå konflikter.

Lad os overveje en konfliktfyldt situation som et eksempel: der er en gren develop, fra hvilken to grene er afledt: feature1 og feature2, som ikke har konflikter med develop, men som har konflikter med hinanden. Opgaven er at udføre en sammenkobling af begge grene i develop. I dette tilfælde anbefales det først at udføre fletningen af en af grenene til develop, og derefter fletningen af develop til den resterende gren, samtidig med at man løser konflikterne i den resterende gren, hvorefter den sidste gren kan flettes ind i develop. Under konfliktløsningen kan det være nødvendigt at rette migrationsfilen i den sidste gren, så den svarer til det endelige dump, der inkluderer resultaterne af sammenkoblingen.

SchemaKeeper

Takket være tilgængeligheden af et dump af den aktuelle database-struktur i VCS opstår muligheden for at kontrollere produktionsdatabasen for nøjagtig overensstemmelse med den krævede struktur. Dette garanterer, at alle ændringer, som udviklerne havde til hensigt, er blevet overført til produktionsdatabasen.

Da DDL i PostgreSQL er transaktionel, det anbefales at følge følgende rækkefølge for deployment, så man ved en uventet fejl kan udføre en "smertefri" operation: ROLLBACK:

Start transaktionen
Udfør alle migrationer i transaktionen
I den samme transaktion udfør The source code of stored procedures can be modified just like regular application source code. You can add/remove new lines in the stored procedure code and immediately commit changes to the version control system, or create/delete stored procedures by creating/deleting the corresponding files in the dump directory.
Uden at afslutte transaktionen, udfør verifyDump. Hvis der ikke er fejl, udfør COMMIT. Hvis der er fejl, udfør ROLLBACK

Disse trin kan let indarbejdes i eksisterende tilgange til deployment af applikationer, herunder zero-downtime.

Konklusion

Takket være de ovenfor beskrevne metoder kan man maksimere ydeevnen af "PHP + PostgreSQL" projekter, idet man ofrer en relativt lille mængde udviklingskomfort sammenlignet med implementeringen af al forretningslogik i applikationens hovedkode. Desuden virker databehandlingen i . Testning med andre sprog er ikke foretaget, så brugen kan muligvis ikke være så effektiv eller umulig. ofte mere gennemsigtig og kræver mindre kode end den samme funktionalitet, der er skrevet i PHP.

Kilde: habr.com