Postgre schema compare

Adatbázis: SQL, XML DB

Sziasztok!

Postgresql-hez keresek schema compare tool-t, ami kigenerálja a változásokat. Milyen megoldások vannak erre? Visual Studio-val dolgozunk, abban van SQL Project template, amiben van schema compare, ami működik (többé-kevésbé) SQL Serverrel. Kerestem Visual Studio Marketplace-en, nem igazán találtam (vagy rosszul kerestem). A google találatokat végignézve nem igazán tudtam eldönteni, hogy melyikre lenne szükségem. Személyes tapasztalat érdekelne leginkább.

Szerk.: Olyanra gondolok, hogy dev-en hozzáadunk egy új oszlopot a táblához és a dev-et összehasonlítva az UAT-tal ki tudja generálni az ALTER scriptet.

  • 991 megtekintés

( nydn | 2019. 10. 14., h – 16:00 )

A Liquibase elvileg tud ilyet, de őszintén szólva még sosem volt rá szükségem, így nem tudom mennyire megbízható/használható ez a funkció.

( joco01 v | 2019. 10. 14., h – 16:00 )

Szerintem fordítva ülsz a lovon. A source of truth ne az adatbázis legyen, hanem a forráskód. Nézd meg, mit csinál az entity framework migrations pl.

Nem feltétlenül ül fordítva a lovon. A code-first egy esetben működik: ha azt az adatbázist pontosan egy eszköz fogja használni.
Ha több, egymástól függetlenül (független kiadási ciklus szerint) fejlesztett tool is fogja használni, akkor bizony a source of truth az egy DB szinten leírt adatmodell, amit minden tool ismer.

Ugyanis ilyenkor az adatbázisstruktúra életciklusa, verziózása nem egyetlen szoftvertől függ - hanem sok szoftver függ magától az adatbázistól.

Most is fejlesztünk olyan adatbázisra, amit (sajnos) sok app használ. De továbbra is igaz az, amit írtam, hogy a séma forráskódja a verziókezelőben a source of truth. Ebből generálódik a fizikai adatbázis szerkezet, és ebből generálódnak ORM-ek meg egyebek is (tehát a sok app kb. libraryként használja a közös séma leírót).

Melyik ORM tud SQL DDL scriptből leírót építeni? Én csak azzal találkoztam, ami fizikai DB-t fejtett vissza. Ott önmagában az, hogy a DDL szkript verziókezelt, semmit nem ér.

Szóval ott ilyenkor bizony a fizikai DB a source of truth.

Az egy ettől teljesen független kérdés, hogy ezt a fizikai DB-t felépítő leírót (a DDL scriptet) verziókezelten tárolod, és így tudod elérni, hogy akárhányszor (CI/CD, tesztelés, dev környezet kiépítése) fel tudod építeni a 0-ról a fizikai DB-t.

Igaz, de az életben sokszor előfordul, hogy a source of truth ide, source of truth oda, nem érnek össze dolgok és mégis jó lenne összehasonlítani két adatbázis sémát. Arról nem beszélve, hogy akkor is hasznos egy ilyen tool, ha nincs kezedben forráskód, urambocsá' nincs entity framework és így nincsen migrations meg flyway, meg liquibase sem. Ilyen helyztere tudnál javasolni egy jó eszközt?
--
Desktop: Windows10 | Server: CentOS

( andrewjsi | 2019. 10. 14., h – 16:22 )

rejtett up - én is keresem a jó megoldást

Mi az apgdiff -et használjuk. Két dump fájlt vár, és legenerálja az SQL parancsokat egy harmadik fájlba. Nem tökéletes, sokszor szükség van arra, hogy megtisztítsuk a bemeneti fájlokat, mielőtt ráeresztjük, de alapvetően teszi a dolgát, leszámítva, hogy egy nagy Java bloat.

A migra pedig két PostgreSQL szerverre csatlakozik és úgy végzi el az összehasonlítást. Python-ban írták. Ha szépen haladnak vele, akkor idővel sokkal jobb lesz és kevésbé problémás, mint az apgdiff.

( persicsb | 2019. 10. 14., h – 16:47 )

Az ilyen schema compare toolokkal egy nagy baj van.

Tegyük fel, hogy te átneveznél egy oszlopot egy 3 oszlopos táblában.
A compare tool annyit lát, hogy volt 3 oszlop, lett 3 oszlop, és nem tudja eldönteni, hogy ez tényleg csak átnevezés (azaz ALTER TABLE t RENAME COLUMN c TO c2 parancsot generáljon, így az adatok megmaradnak), vagy egy column törlődik, és helyette keletkezik egy új (azaz egy ALTER TABLE DROP COLUMN + ADD COLUMN párost) generáljon, amivel elvesznek az adatok.

Ehhez mindenképpen kell valami leíró, hogy mi történt a táblával, ezt nem lehet sima diffel automatikusan kitalálni a kezdő és végállapotból, ha a struktúrák adottak csak.

Ezeket VS-ban csináljuk, ott ha átnevezel egy táblát, oszlopot, indexet, akkor jegyzi, hogy ott nem egy törlés és egy létrehozás van, hanem átnevezés.
Sőt, az MS-nél nem tudod megmondani új oszlop hozzáadásánál, hogy melyik mező elé/mögé tegye, viszont a schema compare van annyira intelligens, hogy úgy generálja ki a szkriptet.

-----------
Akkor beszélsz igazán jól angolul, ha egy angol viccen őszintén tudsz nevetni

( zsolt | 2019. 10. 15., k – 01:47 )

Nekem a git bevált erre (is).
Egyébként nem Postgre, hanem Postgres.
Legalábbis mikor még nem volt hozzá SQL, ez volt a neve.

( persicsb | 2019. 10. 15., k – 13:56 )

"Szerk.: Olyanra gondolok, hogy dev-en hozzáadunk egy új oszlopot a táblához és a dev-et összehasonlítva az UAT-tal ki tudja generálni az ALTER scriptet."

Na, ilyet nem csinálunk. DB változtatást nem kézzel csinálunk, mert nem verziókövetett, hogy ki mikor mit csesztetett az adatbázisban.
Leírod magát az ALTER scriptet egy SQL-be, commitolod, átmegy review-n, aztán deploykor lefuttatja valami (akár maga az alkalmazás, akár egy külön DB menedzsment eszköz).

"Na, ilyet nem csinálunk"

De.
Sql Server esetében:
1. Ez van a db project-ben és verziókövetőben:
CREATE TABLE A (Id INT NOT NULL, FooColumn VARCHAR(MAX))
2. Localon megcsinálod az alter table-t, hozzáadod FooColumn2-t
3. Schema compare local > db project
4. Ez van a db project-ben
CREATE TABLE A (Id INT NOT NULL, FooColumn VARCHAR(MAX), FooColumn2 VARCHAR(MAX))
5. Commit-Push/check-in
6. Schema compare > Generate script bármelyik környezetre

MINDEN módosítás meglesz a verziókövetőben, a rollback script egyszerűen elkészíthető az irány megfordításával. Ez így bevált és így működik. Hasonlót keresek PG-hez.
Ha azt a mezőt még bele kell írni 4 tároltba, akkor majd egyesével kézzel módosítod? A '00-s években még így ment, aztán Isten megteremtette a db projectet.

-----------
Akkor beszélsz igazán jól angolul, ha egy angol viccen őszintén tudsz nevetni

Tehát a verziókezelőben egy helyen csak CREATE scriptek vannak, egy adott időpillanatra vonatkozó állapotot leíró DDL.
Akkor hogyan lesz ebből rollback script (ami ugye változásokat, azaz két időpillanatra vonatkozó állapotok közötti eltérések megvalósításának oda-vissza irányát írják le)?

Csinálsz két checkoutot, majd a két create alapján egy diffet?

Na ne már.

Sokkal járhatóbb út, és egyből látszik a verziózás is, ha van egy alapstruktúrád, meg a hozzá képest történt változások szépen sorrendben.
Majd a DB management eszköz pedig végrehajtja azokata scripteket, amikkel egy adott verzióról egy adott verzióra lehet downgradelni/upgradelni a DB-t kérésre.
Például megmondod, hogy upgradeljen v20191015-re. Vagy downgradeljen v20190923-ra.

https://www.liquibase.org/
Ez a változásleíró lehet SQL DDL is, de van XML leírója is, csak az a kezelt DB-k közös metszetét tudja csak, nem tud minden dolgoz kifejezni, ami SQL DDL-lel kifejezhető.
Ha akarom, akkor futtatom kézzel lokális DB-n, futtatom CI-ből parancssorból, futtatom akkor, amikor az alkalmazás deployolódik stb.