RSS Guard 3.9.0 a co dál (diskuse)

[Max]

Moc pěkná app, postupně si tam láduju věci.
díky
Zdar Max

[skunkOS]

Už opravenej první bug v 3.9.0 - nahrál sem nový balíčky. :D

[Josef Kufner]

Ten způsob údržby a aktualizace databáze, jak ho máš, je asi jeden z nejlepších. Dělám to skoro stejně. Jen namísto čísla verze si ukládám, které skripty byly provedeny a kdy. Takže migrace vypadá tak, že vemu seznam skriptů, odečtu ty provedené a provedu neprovedené. Na konci každého skriptu pak mám INSERT, že se to povedlo (namísto tvého update). Výhoda je, že když mergneš dvě větve s dvěma změnama v databázi, tak nenastane konflikt.

[skunkOS]

O něčem takovém jsem taky uvažoval. Samotný mechanismus jak ho mám funguje vlastně docela dobře, akorát za ty roky se tam nahromadilo těch změn dost a už to začínalo bobtnat. Ta vrstva přímo volá o zjednodušení.

[Josef Kufner]

Takový SQL changelog klidně může mít pár stovek skriptů. Zachovej klid, máš jich tam zatím docela málo

Přijde mi jen trochu nešikovný ten způsob pojmenování. Osvědčilo se mi to číslovat datumem (nepoužívám sekvenční řady; tam bych dal alespoň nevýznamné nuly) a typ databáze bych dal na konec, aby skripty pro stejné změny byly u sebe. Ale jinak to nech, nic o moc lepšího nevymyslíš.

[skunkOS]

Jasný, ten objem by mi nevadil, ale byly tam nějaké kompromisy a špatná rozhodnutí, která následně zbytečně komplikují jiný kód, který se bude dát zjednodušit, řádově nejspíš stovky řádků pryč, možná tisíc či víc.

[xkucf03]

Případně je tu Liquibase – dá se použít buď přímo jako hotový produkt, nebo pro inspiraci při psaní vlastního řešení.

[Josef Kufner]

Takových nástrojů je spousta. Hodně jich je zbytečně komplikovaných.

Nakonec stejně není použitelné nic jiného než SQL skript, neboť je potřeba migrovat i data. Různé reprezentace DB schématu a hledání rozdílů jsou v tomto ohledu na nic. Každá automatika tady znamená pravděpodobnou ztrátu dat. Jediné, k čemu to je tak nějak použitelné je, že si člověk nakliká co chce a pak si nechá vygenerovat skript, který to udělá, ale ten pak stejně musí zkontrolovat a upravit, aby nedošlo ke ztrátám dat, takže to vlastně až tak moc nepomůže.

Nejvíce se mi osvědčilo si vykopírovávat SQL dotazy z logu klienta, kterým DB měním a z toho poskládat migraci.

[xkucf03]

Liquibase jsme používali mj. na projektu, kde se nasazovalo na více různých databázových systémů – přidává to tam určitou portabilitu a abstrakci. Když ty změny definuješ v XML a ne ve formě SQL skriptu pro specifický systém, tak pro tebe Liquibase vygeneruje SQL skripty pro jednotlivé systémy. Pokud by automatika nestačila, tak si tam vždycky můžeš udělat podmíněný blok, který se pustí jen na určitém DBMS.

To je jen jedna z mnoha výhod.

Na druhou stranu souhlasím, že je to poměrně komplexní řešení. Pokud by šlo o můj vlastní projekt, kde mám na všechno dost času, tak bych pravděpodobně šel taky cestou vlastních skriptů – je to tedy trochu NIH, ale zase minimální komplexita a řešení přesně dle mých potřeb – za cenu toho, že si s tím musím pohrát a nestačí stáhnout z internetu hotový nástroj a začít ho používat.

Jinak, co jsem viděl u zákazníků různé jejich upgradovací skripty, tak to bylo většinou slabší – napsané kdysi někým, kdo už tam není, a ostatní se na to bojí sáhnout… někdy se pak právě přecházelo na ten Liquibase.

Oboje má svoje. Jak jsem psal, pro vlastní projekt, o který se budu starat pořád já, spíš vlastní řešení. Ale někam do větší firmy, kde je pravděpodobná vyšší fluktuace lidí, bych doporučil spíš ten Liquibase. Ono už jen zdokumentovat to vlastní řešení, aby ho mohli používat ostatní a ne jen jeho autor, zabere dost času – a ten si přepočti na peníze.

[Josef Kufner]

Ono to není vůbec NIH. Migrace má nějak vyřešené v podstatě každý framework. Třeba Doctrine má jednotlivé migrace jako třídy s metodami up() a down(), kam si napíšeš ty SQL dotazy (ať už přímo, nebo tím udělátkem, co tam je na manipulaci schématem, nebo obojím) a do tabulky si píše, co už bylo provedeno. Laravel má cca totéž. Phinx je samostatný nástroj, který dělá to samé. Liquibase vypadá jako poněkud overengineered věc, ale tak nějak v hromadě zbytečností tam vykukuje ten samý koncept …

[xkucf03]

Tak to mluvíš zase spíš o ORM – ano, můžeš si napsat třídy a pak si pod nimi nechat automagicky vygenerovat tabulky… ale to mi nepřijde jako nejšťastnější cesta. Je to takové rychlé a špinavé řešení, někdy použitelné. Ale já přeci jen radši začínám od toho modelu – databázi beru jako něco trvalého, zatímco aplikace, knihovny a frameworky jsou pomíjivé – v čase se mění, nahrazují nebo jich může být současně nad jednou databází několik. Proto se nechci tolik vázat na konkrétní programovací jazyk nebo framework.

Pak je tu otázka rolí/lidí – kdo by ten datový model měl navrhovat a udržovat. Když se to děje ad-hoc v rámci běžného vývoje a implementace jednotlivých úkolů nebo dokonce oprav chyb, tak to nedopadá moc dobře. Někdy je na to vyhrazena separátní role. Nebo to dělá aspoň seniorní vývojář/architekt, který má blízko k relačním databázím. Případně když je část logiky v procedurálním SQL, tak se o ten model nejspíš budou starat lidé, kteří píší to procedurální SQL, protože k relačním databázím mají bližší vztah než běžný javista, phpčkář atd.

[Josef Kufner]

Nemluvím o ORM, mluvím o Doctrine DBAL, což je jen lehká nadstavba nad databázovým SQL klientem (PDO) a řeší nějaké detaily, nekompatibility a tak podobně. Doctrine ORM je postavené nad tím a umí dělat ty rozdíly a generovat migrace podle změn schématu, ale nemám to rád (jak už jsem psal).

Ještě více než databáze je však důležitá spodní vrstva aplikace, která k databázi přistupuje, obvykle zvaná model. Typicky tvoří spolu s databází nedělitelný celek a tepve API modelu je to, co je trvanlivé. Databáze samotná totiž jen uchovává data, ale až model datům dává význam a obsahuje další podmínky a pravidla (a třeba tu deserializaci JSONu).

Co se rolí ve vývoji týče, je to spíš o code review. Na začátku to chce nastřelit někým zkušeným, ale stejně tam pak je mnoho změn a tedy i malých migrací. Často však je z podstaty věci dané, jak databáze bude vypadat a je potřeba jen někdo, kdo udělá správně indexy a trochu to učeše.

[skunkOS]

Je to zajímavé, ale přesně jak píšete. Přišel mi pod ruku jeden software (velmi komplexní, milion řádků), kde mají DB vrstvu řešenou také sadou inicializačních/aktualizačních skriptů a je to šílené. Já osobně se od toho kódu distancuji, ale je normální, že při každé nové verzi toho SW je v těch skriptech nová chyba, která defacto znemožní instalaci/upgrade programu.

U svých programů jsem docela dost důsledný a dělám ty skripty přehledné, vždy je vyzkouším oproti různým předchozím verzím relačního schématu či prázdné DB atp.

Další věc je, že některé drobnější nuance v těch DB se řeší v různých RDBMS jinak. Někde nejsou zapnuté "tvrdé" cizí klíče by default (SQLite), někde se připojujete přímo v connection ke konkrétní DB, někde je možné mezi DB v SQL přepínat, někde bojujete s kódováním/collation tabulek, sloupců, připojení, někde ne, někde je specifický datový typ pro vaše potřeby, v jiném RDBMS analogicky typ není, takže radší zvolíte obecnější datový typ atp. Už jen to, co jsem napsal mě spíš utvrzuje v tom, že meta-generátor SQL skriptů musí být ultra jednoduchý a přímočarý, aby mě v mém use-case zajímal.

[Josef Kufner]

vždy je vyzkouším oproti různým předchozím verzím relačního schématu

To je něco, co by nikdy nemělo nastat. Máš mít lineární posloupnost změn (SQL skriptů), které jdou vždy z jedné definované verze do druhé. Takže ať se spustí migrace nad jakoukoliv verzí schematu databáze, tak se jen vyberou ty správné SQL skripty a ty krok po kroku projdou všemi verzemi až do té aktuální. Tedy každá změna pracuje jen s jedním předchozím stavem a vyprodukuje jeden následující stav.

Pokud máš různé DB, tak budeš mít různé sady SQL skriptů. Pokud chceš přepínat, tak spustíš v cílové databázi migrace z nuly, čímž vytvoříš prázdnou databázi s aktuálním schematem, a pak budeš mít skript na export a import, či zálohu a obnovu.

Pokud někde máš jiné kódovaní, jiný typ sloupce, nebo něco takového, tak tam prostě máš bordel a první co máš udělat je, že bordel uklidíš a databázi dostaneš do jednoho z definovaných stavů (verzí). Pokud je nějaká část schematu proměnlivá, tak má být zdokumentováno jak se může měnit a migrace s tím musí počítat. Lepší ale je mít pár zbytečných sloupečků pro nepoužívané funkce (v dané instalaci), než proměnlivé schema.

[skunkOS]

Však ano, přesně takto to mám, jen to před vydáním trošku protestuju, toť vše.

[skunkOS]

"pár zbytečných sloupečků pro nepoužívané funkce (v dané instalaci), než proměnlivé schema" - a tohle přesně právě píšu, bohužel jsem na užitečnost přišel až po pár letech.

Prostě bude jedna tabulka, kde se některé custom sloupce nepoužijí nebo plugin řekne, že mají být použité na něco jiného, než mít X tabulek s různými strukturami, pak aby se v tom prasel vyznalo.

[Josef Kufner]

Pokud bych chtěl, aby plugin měl možnost ukládat data, tak by plugin dostal svou tabulku (tedy spíše prefix pro názvy tabulek) a byl povinen dodat odpovídající migrace. Když se plugin odinstaluje, je naprosto jasné, které tabulky můžeme zahodit. Když se dělají migrace vlastní aplikace, tak to plugin nerozdrbe (ani jedním směrem) a jediné, co může nastat, je problém s existencí cizích klíčů, které nějaké změny zablokují.

[skunkOS]

Ano. Akorát, že v té mé infrastruktuře plugin na 95% zatím vlastní tabulky nepotřeboval, protože ty pluginy zpracovávají a produkují unifikovaná data ve formě "zpráviček", které mají pro všechny pluginy v zásadě stejnou sadu atributů.

Takové ty plugin-specific nuance jsem v zásadě jen v tom, že synchronizované pluginy k zprávičkám přiřazují service-specific ID, ale každá zpráva má ID, jen jeho generátorem je vždy někdo jiný - tudíž sloupec je pro všechny společný.

Nejvíc těch plugin-specific věcí je právě v tabulce "Accounts", kde některé účtu mají jméno/heslo, některé ne, některé umí limitovat počet stahovaných zpráv, některé ukládají oauth tokeny, jiné ne atp. A to, jaká data požaduje zapisovat jsem právě přidal do API a každý plugin si tak nově může říct, jaká data (z jakých property toho accountího objektu) chce ukládat, zda je chce před uložením (de)šifrovat atp. Uvidíme, jestli během re-implementace narazím na nějaký blocker, že jsem něco nedomyslel.

[Josef Kufner]

Takové ty plugin-specific nuance jsem v zásadě jen v tom, že synchronizované pluginy k zprávičkám přiřazují service-specific ID, ale každá zpráva má ID, jen jeho generátorem je vždy někdo jiný - tudíž sloupec je pro všechny společný.

To je jeden textový sloupec dostatečné délky, např. varchar(255). To není v ničem problém.

Nejvíc těch plugin-specific věcí je právě v tabulce "Accounts", kde některé účtu mají jméno/heslo, některé ne, některé umí [...]

Na to je nejlepší textový sloupec, kam se parametry serializují v JSON. Z akademického pohledu je to děsná prasárna, ale z praktického je to to nejlepší, co jde udělat. Na typické časté věci (např. uživatelské jméno a heslo) si tam necháš nullable sloupeček a na ten zbytek blob s JSON. Z pohledu databáze to bude sloupec trochu exotického typu a tobě to ušetří spousty potíží.

[skunkOS]

Udělám to tak, ano, asi to nebude úplně kosher a docent Vychodil se "obrací v hrobě", ale pro vyšší dobro je třeba činit oběti.

[xkucf03]

Obecně by modul (plug-in) měl záviset na jádře, ale nikoli jádro na modulu. Moduly by pak mělo jít psát a přidávat, aniž by se v jádře cokoli měnilo. Na to je potřeba tam mít připravená rozhraní. Co se týče dat, tak modul může mít vlastní schéma (pokud ho DB, např. PostgreSQL, podporuje) nebo v horším případě ten prefix tabulek. Případně může ukládat data do nějakých generických sloupečků třeba v XML (dá se to i indexovat, ale o ty indexy se pak musí někdo ručně starat). Nebo i do EAV – přestože to mnozí považují za „anti-pattern“, jsou případy, kdy je to funkční a smysluplné řešení.

Závislost směrem z jádra k modulu by neměla být ani na úrovni datového modelu. Cizí klíče by tam buď neměly být nebo by se mělo mazat kaskádovitě (modul přijde o svoje data, když se smaže nadřazená entita v jádře, ale to by nemělo vadit). Určitě by modul neměl narušovat funkci jádra tím, že si tam nasmolí nějaké svoje klíče nebo jiná integritní omezení a pak bude blokovat dříve běžně prováděné akce.

[skunkOS]

Ano, tak to samozřejmě mám. Ty pluginy používají pouze "helper" věci z API. Mají dobře definované API, jsou docela dost dobře oddělené od ostatního kódu a lze je poměrně jednoduše oddělit i do samostatných knihoven, o což ale zatím nebyl zájem.

Jelikož všechny pluginy nemají žádné extra závilosti, tak v současné době je bundluju přímo do binárky hlavní aplikace, resp. do hlavní knihovny.

Vlastní schémata pro moduly zatím striktně zakazuji a modul-specific data jsou potřeba jen a pouze v jedné tabulce a nyní je budu řešit skrze serializovaný JSON v extra sloupci.

Závislosti směrem z jádra do modulů je 0. Moduly implementují C++ rozhraní (virtual metody) a ty volá jádro. Toť vše.

[xkucf03]

To je něco, co by nikdy nemělo nastat. Máš mít lineární posloupnost změn (SQL skriptů), které jdou vždy z jedné definované verze do druhé. Takže ať se spustí migrace nad jakoukoliv verzí schematu databáze, tak se jen vyberou ty správné SQL skripty a ty krok po kroku projdou všemi verzemi až do té aktuální.

Tohle funguje dobře u malých projektů, kde máš těch změn jen pár. Pokud jde o něco většího (spousty tabulek, pohledů, procedur, funkcí…) a s delší historií (každý měsíc se nasazuje řada změn), tak to přestává být použitelné. Kdyby sis tímto způsobem chtěl vytvořit třeba vývojové/testovací prostředí, tak bys musel pokaždé sjíždět inkrementy za posledních deset nebo víc let… To by ses jen tak nedočkal a bylo by to obrovsky neefektivní. Ideál je, když nové prostředí můžeš vytvořit během pár vteřin, pustit na něm nějaké testy, a pak to klidně celé zahodit.

Proto se pak dělají záchytné body (snapshoty), které obsahují kompletní stav k nějaké verzi – a inkrementálně se donasadí jen těch pár posledních změn.

Pak je dobré mít ověřené, že se na aktuální verzi dostaneš z libovolného záchytného bodu a i úplně od nuly tím, že projdeš celou historií – a výsledek bude vždy stejný.

[Josef Kufner]

V tom máš naprostou pravdu, avšak takové snapshoty jsou jen přirozená optimalizace používání té lineární posloupnosti změn. Je to v podstatě forma kešování.

Dává smysl mít snapshot, ze kterého staruješ testy a který se používá při vývoji. Pak je rozumné mít snapshoty u každé vydané verze, kdy čerstvá instalace použije snapshot a aktualizace použije migrace (kterých pak je jen relativně málo).

Pak je dobré mít ověřené, že se na aktuální verzi dostaneš z libovolného záchytného bodu a i úplně od nuly tím, že projdeš celou historií – a výsledek bude vždy stejný.

Toto je velmi podstatné. Testy, které ověří konzistenci snapshotů jsou v podstatě nutnost. Je pak záležitost politiky podpory starých verzí, kolik se toho bude testovat – např. jen od snapshotu předminulé major verze, nebo klidně celou historii u malé/mladé aplikace.

Stále však platí, že snapshoty jsou jen optimalizace. Primární zdroj je posloupnost změn.

[skunkOS]

"Jediné, k čemu to je tak nějak použitelné je, že si člověk nakliká co chce a pak si nechá vygenerovat skript, který to udělá, ale ten pak stejně musí zkontrolovat a upravit, aby nedošlo ke ztrátám dat, takže to vlastně až tak moc nepomůže."

Doporučíte nějaký takový projekt? Hlavně jednoduchý, žádný moloch.

[Josef Kufner]

Nedoporučím, neboť jsem to skutečně použil sotva párkrát v životě. V podstatě si stačí udělat dumpy bez dat a pustit na to diff. Ono totiž ty rozdíly stejně je potřeba pořešit ručně a hlavně zkontrolovat, že se při tom nerozdrbou data, případně data vhodně konvertovat, udělat si záložní kopie tabulek či sloupců a tak vůbec. Jakmile je v databázi uklizeno, tak je možné začít používat migrace a tam zas není potřeba dělat rozdíly, stačí průběžně kopírovat SQL dotazy z logu klienta.

[skunkOS]

Divám se na to a jako nevypadá to špatně a kdybych těch databází měl podporovat hodně, asi by mě to i víc zajímalo, ale já jsem takovej oldschool. Tohle by prostě byl další (byť asi měkká) závislost projektu, navíc mám prostě rád takovou tu absolutní kontrolu, vědět jak přesně to SQL vypadá atp.

Navíc, to není asi OSS jestli se dobře dívám, přijde mi to i takové trošku jak tu někdo psal overengineered.

Kdyby byla nějaká OSS binárka, které bych prostě podstrčil XML meta-definici DB struktur a ta by mi vygenerovala pěkné SQL pro mysql, postgre, sqlite, případně mssql, tak by mě to zajímalo. Muselo by to ale umět i generování "aktualizačních" SQL, pro případ, kdy už nějaké struktury mám, ale potřebuji přidat sloupec, upravit typ sloupce atp. a to s důrazem na zachování dat - tohle by se mi zejména hodilo pro SQLite, kde není možno nedestruktivně přidávat sloupce, musí se vždy zkopírovat stávající tabulka.

[Josef Kufner]

Muselo by to ale umět i generování "aktualizačních" SQL

To je právě ta komplikovaná věc.

Nejlepší řešení je použít to, co v aplikaci tak jako tak používáš. Každá migrace pak bude třída, která má název a metodu na provedení změn (je rozumné jednotlivé migrace automaticky zabalit do transakcí). Při kompilaci si vygeneruješ jejich seznam. Migrační nástroj pak vypadá tak, že koukne, které migrace byly provedeny a provede ty, které nebyly (v definovaném pořadí). Potřebuješ na to vylistovat seznam migrací, udělat select do tabuky s provedenými migracemi a odečíst provedené od dostupných. To je celé. Nějakých 200 řádek kódu. Výhodou je, že migrace jsou plně integrované v aplikaci a nemusíš řešit externí nástroje. Při spuštění spustíš migrace a hotovo.

Představa jednotného schématu a generování změn je sice lákavá, ale praxe ukazuje, že to za to nestojí. Když se podíváš na různá ORM, tak ty to dělají, ale také schovávají většinu z toho, co databáze umí, aby to tak nějak šlo smysluplně udělat. Navíc to pořád neřeší změny v datech.

Osvědčilo se mi používat query builder. Když se nějaké dotazy vyskytují často, tak si uděláš metodu, která takový dotaz sestaví. Vedle častých selectů a insertů můžeš mít třeba i přidávání sloupečků. Když pak migrace je běžná (C++) třída, tak máš k dispozici ten samý query builder jako ve zbytku aplikace. Můžeš i zkoumat, zda něco bylo či nebylo provedeno (např. přidej sloupec, pokud chybí a tím uklízet bordel).

[skunkOS]

+1

Jinak už teď, když jsem sotva začal jsem odstranil snad 1000+ řádků kódu a najednou vidím jak je ten kód reduntantní. Se samotným návrhmem DB struktur na tom nejsem moc dobře, nemám v tom moc zkušeností. Kvůli rozdílnostem v relačních schématech v jednotlivých tabulkách pro uchovávání různých "účtů" tam byla spousta kódu, která se teď smazala

https://github.com/martinrotter/rssguard/commit/4dbf5043bbfe775f6c10f1391fb702d004fd78fa

protože ty tabulky nyní jdou také pryč a místo nich nastupuje jedna trošku unifikovanější tabulka

https://github.com/martinrotter/rssguard/blob/version-4/resources/sql/db_init_sqlite.sql#L8

kde se budou account-specifická data dynamicky mapovat na "custom" sloupce v DB, kterých sem si tam do rezervy udělal 20, přičemž každý účet jich využívá max tak 11-12, a tak už teď vím, že na tu tabulku nebudu muset chytnout.

Předtím měl každý plugin vlastní sadu metod pro načtení svých "účtů" z DB, teď existuje jedna jediná template metoda pro všechny, stovky řádků pryč. Sice trochu bojuju s kompilací (cirkulární include), ale to už je můj problém.

https://github.com/martinrotter/rssguard/blob/version-4/src/librssguard/miscellaneous/databasequeries.h#L198

[Josef Kufner]

custom_data_1 ... custom_data_20

Jo, dej tam custom_data_json (jak píši o nějaké to vlákno výše) a při selectu to deserializuj do QHash<QString, QString>, tedy hloupé key-value úložiště.

Pokud bys měl nutkání tam dávat další tabulku s EAV, tak se na to vybodni.

[Josef Kufner]

… I když koukám, že Qt už má podporu JSON přímo v sobě. Asi by to stálo za použití.

[skunkOS]

Je to dobrý nápad. Nechápu, že mne to taky nenapadlo.

[Josef Kufner]

Z toho si nic nedělej. Já k tomu dospěl až po několika letech praxe a pár bolavých zkušenostech. Je to takový ten druh řešení, který je příliš jednoduchý, než aby byl snadno objevitelný. A také takový, který je teoreticky děsně špatně a proti všemu, co se učí, ale v praxi je to jednoduché a efektivní. Teprve s příchodem NoSQL databází se tento přístup vzal na milost a některé databáze pro to mají od nedávna i podporu (PostgreSQL od 2012).

[xkucf03]

Navíc, to není asi OSS jestli se dobře dívám

To se bohužel trochu změnilo od posledně, co jsem to používal. Zdrojáky jsou pořád k dispozici (pod svobodnou licencí Apache 2.0), ale teď tě mnohem víc tlačí k tomu, aby sis koupil placenou verzi. Pro jistotu ty zdrojáky zálohuji.

přijde mi to i takové trošku jak tu někdo psal overengineered.

Tady to chce znát míru a proporce. Když budu mít velký projekt, kde už tak je hodně komplexních knihoven a frameworků, tak ten Liquibase už nepředstavuje významný nárůst komplexity. Ale zatáhnout Liquibase jako závislost do nějakého minimalistického softwaru – z toho bych neměl dobrý pocit.

Muselo by to ale umět i generování "aktualizačních" SQL

Příkazy končící na SQL, jako updateSQL, neprovádí změny v databázi, ale generují SQL skript. Někdy se to hodí, protože jsou prostředí, kde tě nenechají spouštět nějaký tvůj nástroj (Liquibase) nebo ti tam ani nedají přístup a jen řeknou, ať jim dáš SQL skript a že si ho pustí sami.

Nicméně pokud by nastaly nějaké komplikace nebo bylo potřeba změny vrátit zpět, tak si to pak člověk musí řešit sám. (jinak Liquibase má i příkaz rollback, kterým jde změny vracet zpátky).

pro případ, kdy už nějaké struktury mám, ale potřebuji přidat sloupec, upravit typ sloupce atp. a to s důrazem na zachování dat - tohle by se mi zejména hodilo pro SQLite, kde není možno nedestruktivně přidávat sloupce, musí se vždy zkopírovat stávající tabulka.

Pokud už databáze existuje a dosud nebyla spravovaná přes Liquibase, tak k tomu je tu příkaz generateChangeLog, který ze stávající DB vygeneruje to XML – a na něj se pak dá navázat dalšími inkrementy.

[Ruža Becelin]

Dobrá práce, díky.

[skunkOS]

+1