A cikk célja, hogy a schema-keeper könyvtár példáján bemutassa schema-keeper azokat az eszközöket, amelyek jelentősen megkönnyítik az adatbázisok fejlesztési folyamatát PHP-projektek keretében, amelyek PostgreSQL adatbázis-kezelőt használnak.

Ez a cikk elsősorban azok számára lesz hasznos, akik maximálisan kihasználják a PostgreSQL lehetőségeit, de problémákba ütköznek a DB-be áttelepített üzleti logika fenntartásával.

A cikk nem tárgyalja az üzleti logika adatbázisban történő tárolásának előnyeit vagy hátrányait. Feltételezhető, hogy az olvasó már meghozta ezt a döntést.

A következő kérdéseket fogjuk megvizsgálni:

1. Milyen formában tároljuk az adatbázis struktúrájának dumpját a verziókezelő rendszerben (a továbbiakban VCS)
2. Hogyan kövessük nyomon az adatbázis struktúrájának változásait a dump mentése után
3. Hogyan vigyük át az adatbázis struktúrájának változásait más környezetekbe konfliktusok és óriási migrációs fájlok nélkül
4. Hogyan állítsuk be a párhuzamos munkát több fejlesztő számára egy projekten
5. Hogyan végezzünk biztonságos telepítést az adatbázis struktúrájának nagyobb mennyiségű változásaival a production környezetben
   

   SchemaKeeper a tárolt eljárásokkal való munkára van optimalizálva, amelyeket PL/pgSQLnyelven írtak. Más nyelvekkel végzett tesztelés nem történt, ezért a használat nem biztos, hogy olyan hatékony, vagy akár lehetetlen.

Milyen formában tároljuk az adatbázis struktúrájának dumpját a VCS-ben

Könyvtár schema-keeper a következő funkcióval rendelkezik saveDump, amely az összes objektum struktúráját az adatbázisból különálló szöveges fájlokká menti. A kimenet egy könyvtár, amely az adatbázis struktúráját tartalmazza, csoportosított fájlokba felosztva, amelyeket könnyen hozzáadhatunk a VCS-hez.

Nézzük meg az objektumok átalakítását fájlokká néhány példával:

Objektum típusa
Séma
Név
Relatív elérési út a fájlhoz

Táblázat
public
accounts
./public/tables/accounts.txt

Tárolt eljárás
public
auth(hash bigint)
./public/functions/auth(int8).sql

Képviselet
booking
tariffs
./booking/views/tariffs.txt

A fájlok tartalma az adott adatbázis-objektum struktúrájának szöveges megjelenítése. Például a tárolt eljárások esetén a fájl tartalma a tárolt eljárás teljes definícióját tartalmazza, amely a következő blokkban kezdődik CREATE OR REPLACE FUNCTION.

Ahogy a fenti táblázatból látható, a fájl elérési útja tartalmazza az objektum típusára, sémájára és nevére vonatkozó információkat. Ez a megközelítés megkönnyíti a dump navigálását és a DB változásainak kódellenőrzését.

Kiterjesztés .sql az eljárásokat tartalmazó fájlokhoz választották az IDE automatikus adatbázis-interakciós eszközeinek biztosítására a fájl megnyitásakor.

Hogyan kövessük nyomon az adatbázis struktúrájának változásait a dump mentése után

A jelenlegi adatbázis-struktúra dummpja VCS-be mentésével lehetőség nyílik az adatbázis struktúrájában történt változások ellenőrzésére a dump létrehozása után. schema-keeper az adatbázis struktúrájának változásainak azonosítására szolgáló funkciót biztosít verifyDump, amely mellékhatások nélkül visszaadja a különbségekről szóló információt.

Egy alternatív ellenőrzési módszer, hogy ismételten meghívja a funkciót saveDump, megadva ugyanazt a könyvtárat, és ellenőrzi a VCS-ben a változások jelenlétét. Mivel az összes adatbázis-objektum külön fájlokban van tárolva, a VCS csak a módosított objektumokat mutatja.
A módszer fő hátránya, hogy fájlok felülírására van szükség a változások megtekintéséhez.

Hogyan vigyük át az adatbázis struktúrájának változásait más környezetekbe konfliktusok és óriási migrációs fájlok nélkül

A deployDump funkciónak köszönhetően a tárolt eljárások forráskódja pontosan úgy szerkeszthető, mint a szokásos alkalmazásforráskód. Új sorokat lehet hozzáadni/eltávolítani a tárolt eljárások kódjában, és azonnal elküldeni a módosításokat a verziókezelő rendszerbe, vagy tárolt eljárásokat létrehozni/eltávolítani megfelelő fájlok létrehozásával/eltávolításával a dump könyvtárában.

Például egy új tárolt eljárás létrehozásához a public sémában elegendő új fájlt létrehozni az .sql raddb/mods-available .public/functionskiterjesztéssel, beletenni a tárolt eljárás forráskódját, beleértve a CREATE OR REPLACE FUNCTIONblokkokat, majd meghívni a deployDumpfunkciót. Hasonlóan működik a tárolt eljárások módosítása és törlése is. Így a kód egyidejűleg kerül a VCS-be és az adatbázisba.

Ha egy tárolt eljárás forráskódjában hiba lép fel, vagy eltérés van a fájl nevének és a tárolt eljárás nevének megfelelően, akkor a deployDump nem hajtódik végre, hibaszöveget jelenít meg. Az adatbázis-dump és az aktuális adatbázis közötti tárolt eljárások eltérése lehetetlen a deployDump.

használata esetén. .sqlÚj tárolt eljárás létrehozásakor nem szükséges manuálisan beírni a helyes fájlnevet. Elég, ha a fájlnak van kiterjesztése. deployDump A meghívás után a hibaüzenet tartalmazni fogja a helyes nevet, amelyet a fájl átnevezésére használhat.

deployDump lehetővé teszi a funkció paramétereinek vagy a visszatérési típusának módosítását további intézkedések nélkül, míg a klasszikus megközelítésnél előbb
kellene végrehajtani a DROP FUNCTION, és csak aztán CREATE OR REPLACE FUNCTION.

Sajnos vannak olyan helyzetek, amikor deployDump nem lehet automatikusan alkalmazni a változtatásokat. Például, ha törlik azt a trigger funkciót, amelyet legalább egy trigger használ. Az ilyen helyzeteket manuálisan kell megoldani migrációs fájlok segítségével.

Ha a változtatások átviteléért a tárolt eljárásokban maga schema-keeper, akkor a többi struktúraváltozás átviteléhez migrációs fájlokat kell használni. Például egy jó könyvtár a migrációk kezelésére: doctrine/migrations.

A migrációkat az indulás előtt kell alkalmazni deployDump. Ez lehetővé teszi, hogy minden struktúraváltozást elvégezzünk, és kezeljük a problémás helyzeteket, így a tárolt eljárások változtatásai később problémamentesen átvitelre kerülnek.

A migrációk kezeléséről részletesebben a következő fejezetekben lesz szó.

Hogyan állítsuk be a párhuzamos munkát több fejlesztő számára egy projekten

Létre kell hozni egy teljes adatbázis-inicializáló skriptet, amelyet a fejlesztő a saját munkaállomásán futtat, hogy a helyi adatbázis struktúráját összhangba hozza a VCS-ben tárolt dump fájllal. A legegyszerűbb, ha az inicializálást három lépésre bontjuk:

1. Egy fájl importálása az alapvető struktúrával, amelyet például base.sql
2. A migrációk alkalmazása
3. Hívás deployDump

base.sql — ez az alap, amelyre a migrációkat alkalmazzák és végrehajtják deployDumpsorok és 1 oszlop: base.sql + migrációk + deployDump = aktuális adatbázis struktúra. Egy ilyen fájl létrehozásához a pg_dumphasználatos, base.sql csak adatbázis nulláról való inicializálása során.

A teljes adatbázis-inicializáló skriptet nevezzük el refresh.sh. A munkafolyamat a következőképpen nézhet ki:

1. A fejlesztő futtatja a környezetében refresh.sh és megkapja az aktuális adatbázis struktúráját
2. A fejlesztő elkezdi a kijelölt feladaton való munkát, módosítva a helyi adatbázist az új funkció igényeire (ALTER TABLE ... ADD COLUMN stb.)
3. A feladat elvégzése után a fejlesztő meghívja a saveDumpfunkciót, hogy rögzítse a VCS-ben a végzett változtatásokat az adatbázisban
4. A fejlesztő újra futtatja a refresh.sh, majd verifyDump, amely most megmutatja a migrációba való beillesztésre váró változások listáját
5. A fejlesztő áthelyezi az összes struktúraváltozást a migrációs fájlba, újra futtatja a refresh.sh és verifyDump, és ha a migráció helyesen lett összeállítva, verifyDump nem mutat eltérést a helyi adatbázis és a tárolt dump között.

A fent említett folyamat összhangban van a gitflow elveivel. Minden ág a VCS-ben tartalmazni fog egy dump verziót, és az ágak egyesítése során a dumpok is egyesülnek. A legtöbb esetben az egyesítés után nincs szükség további lépésekre, de ha különböző ágakban változások történtek, például ugyanazon táblán, konfliktusok léphetnek fel.

Vizsgáljuk meg a konfliktusos helyzetet egy példával: van egy ág, develop, amelyből két ág ágazik le: feature1 és feature2, amelyek között nincsenek konfliktusok, de önmaguk között konfliktusok vannak. Az a feladat, hogy mindkét ágat egyesítsük a develop-ba. Ilyen esetben ajánlott először az egyik ágat egyesíteni a develop-ba, majd a developágat a megmaradt ágba, miközben feloldjuk a konfliktusokat a megmaradt ágból, és ezt követően végezzük el az utolsó ág egyesítését a develop -ba. A konfliktusok feloldásának szakaszában szükséges lehet a migrációs fájl javítása az utolsó ágban, hogy az megfeleljen a végső dumpnak, amely tartalmazza az egyesítések eredményeit. developA VCS által tárolt aktuális adatbázis struktúrájának dumpjának köszönhetően lehetőség nyílik a production adatbázis pontos megfelelőségének ellenőrzésére a kívánt struktúrával. Ez garantálja, hogy a production adatbázisba sikeresen átkerültek minden olyan változás, amelyet a fejlesztők terveztek.

Hogyan végezzünk biztonságos telepítést az adatbázis struktúrájának nagyobb mennyiségű változásaival a production környezetben

A DDL

Mivel a PostgreSQL-ben tranzakcionális , ajánlott a következő telepítési sorrendet betartani, hogy váratlan hiba esetén "fájdalommentesen" végrehajthassuk,Kezdje a tranzakciót ROLLBACK:

1. A tranzakcióban hajtsa végre az összes migrációt
2. Ugyanebben a tranzakcióban hajtsa végre
3. Anélkül, hogy befejezné a tranzakciót, végezze el deployDump
4. . Ha nincsenek hibák, hajtsa végre verifyDump. Ha vannak hibák, végezze el COMMITEzek a lépések könnyen beépíthetők a meglévő alkalmazás telepítési megközelítésekbe, beleértve a zero-downtime-t is. ROLLBACK

A fent említett módszerek segítségével a "PHP + PostgreSQL" projektekből maximális teljesítményt hozhatunk ki, cserébe viszonylag kevés fejlesztési kényelemmel a fő alkalmazáskódban megvalósított teljes üzleti logika implementálásához képest. Sőt, az adatok feldolgozása a

Zárás

gyakran átláthatóbbá válik, és kevesebb kódra van szükség, mint ugyanennek a funkciónak a PHP-ben történő megírásához. PL/pgSQL A cikk célja, hogy a schema-keeper könyvtár példáján keresztül bemutassa azokat az eszközöket, amelyek jelentősen lehetővé teszik.

Forrás: habr.com