Jak pořád nepsat labely

Formulářová pole, validační hlášky, hlavičky seznamů, historie změn entity, … je mnoho míst, kde je potřeba pracovat s popisy polí, která odpovídají vlastnostem nějaké třídy. Článek na blogu AspectWorks představí tip, jak si rutinní činnost zjednodušit.

Spring - MyBatis integrace a něco navíc

Článek popisující možnosti integrace Spring a MyBatis frameworků a představující užitečné rozšíření – factory na automatickou registraci Mapper rozhranní implementovaných XML definicí, jsem napsal pro blog AspectWorks.

Automatický update knihoven Ehcache a Quartz

Zdá se, že automatický update se stává populárním i mezi Java knihovnami. Co si myslíte vy o automatické kontrole aktuálnosti knihovny Ehcache a Quartz? Článek na toto téma jsem napsal pro blog AspectWorks.

Změny v jBPM projektu a jeho budoucnost

Před pár dny zveřejnil JBoss otevřený dopis jBPM komunitě, ve kterém ohlašuje odchod zakladatele jBPM Toma Bayense a dalšího core developera Jorama Barreze z jBPM projektu. K dopisu bylo otevřeno diskuzní vlákno, kde je ale dost mrtvo. Tom Bayens pak na svém blogu naznačuje, že se pouští do implementace nové BPM platformy pod Apache licencí. Z komentářů je pak zřejmé, že Tom Bayens jistě neví, jestli bude práce na jBPM 4 pokračovat (přesněji jestli se bude dál rozvíjet aktuální codebase jBPM 4). JBoss slibuje zveřejnit v řádu týdnů novou roadmapu pro jBMP.

Co si o tom myslíte? Myslíte, že dojde k nějaké formě sloučení jBPM a Drools Flow? To jsou dva projekty z portfolia JBossu, které si začínají velmi konkurovat.

Anketa: Jakým způsobem řešíte verzování datového modelu?

V anketě o používaných způsobech verzovaní datového modelu se sešlo 23 hlasů. Díky za ně. Jasným vítězem jsou "skripty v svn", na druhém místě potom vlastní nástroj pro verzování datového modelu.

Zájemcům o řešení, které může snížit režii spojenou s verzováním a správou modelu, doporučuji svůj přehledový článek o nástroji LiquiBase.

Unit testy nad in-memory databází

V poslední době jsem několikrát narazil na otázku testování dao tříd a volby databáze, nad kterou testy běží. Překvapilo mě, jak kontroverzní otázka to je a jak vyhraněné názory na ni existují. Testujete dao třídy? Píšete unit testy pro cílovou databázi nebo používáte nějakou in-memory variantu jako HSQL? Mají testy s jinou než cílovou databází smysl? Na tyto a související otázky se pokusí odpovědět tento článek.

Testování dao tříd

Předně bych chtěl říct, že rozhodně jsem zastáncem psaní testů dao tříd. Ať už na projektu používáte ORM, přímý přístup přes JDBC nebo objektovou databázi, dao třídy obsahují množství kódu, jehož funkčnost je třeba ověřit. Správnost mapování, skládání dotazů, zpracování result setů, řešení krajních stavů nebo třeba odolnost vůči sql injection mohou být faktory, na které se typický test zaměří. Možnost použití jiné než cílové databázi (tou myslím databázi - Oracle, MySql, ... - která bude použitá v produkčním prostředí) zásadně závisí na tom, jestli se v kódu dao tříd vyskytuje konkrétní sql dialekt. Pokud se dotazujeme přímo přes JDBC a používáme pokročilé vlastnosti databáze, těžko můžeme dao třídy nechat běžet nad něčím jiným. Jaké jsou tedy důvody, které mohou někoho vést k psaní unit testů nad in-memory databází? 

Proč vůbec in-memory databázi používat?

Někdy mohou být zásadní náklady na vytvoření a správu testovacího prostředí. U běžně používaných databází (MySql, Oracle, PostgreSql, ...) většinou nepředstavuje další udržovaná instance velký problém. Existují ale výjimky. Setkal jsem se například s prostředím, kdy byl v produkci použitý Informix a kde vytvoření "další" instance nebylo snadné. Požadavek na novou instanci neznamenal konečnou, ale byl dost nákladný na to, aby ospravedlnil hledání jiných možností.

Dalším důvodem jsou (ne)závislosti, které unit testy potřebují ke svému běhu. V některých prostředích je výhodnější, když unit testy potřebují ke svému běhu jenom svůj a testovaný kód, nikoliv závislosti na dalších systémech včetně databáze. S tím úzce souvisí i opakovatelnost testů, resp. opakovatelnost očekávaného výsledku. Testy nad cílovou databází mohou být citlivější na změny a chyby v testovacích datech, pokud už data před testem obsahují.

Často diskutovaným důvodem je také rychlost spouštění testů. Zastánci testů nad in-memory databází někdy vyzdvihují jejich rychlost, kdy testy nad nimi běží údajně výrazně rychleji než nad cílovou databází. Já tento argument neuznávám. V případě in-memory databáze musíme vedle běhu samotného testu do výsledku započítat určitě vytvoření datového modelu, případně inicializaci dat a to jsou akce, které mohou něco stát.

Unit nebo integrační?

Jsou testy dao tříd nad databází unit testy nebo spíš testy integrační? Odpověď na tuto otázku nemusí ležet v kódu testů, ale v náhledu na ně. Pokud na test nad in-memory databází nahlížíme jako na unit test, můžeme in-memory databázi chápat jako stub, který prostě nahrazuje jednu závislost a dovoluje testu běžet v "izolaci". To je chápání, které je mi blízké. Pokud ale takový přístup nazveme integračním testem, nabízí se otázka jakou má takový test vypovídající hodnotu? O funkčnosti dao třídy toho může test hovořit hodně, ale o integraci s produkční databází velmi málo. Proto testy dao tříd nad in-memory databází za integrační nepovažuji.

Závěr

Jsem zastáncem testů nad in-memory databází tam, kde to má smysl. Dobrými důvody jsou pro mě náklady na správu testovacího prostředí a nezávislost unit testů na dalších systémech. 

Testujete na svých projektech dao třídy? Jakou databázi k testům používáte? Cítíte rozpor mezi použitím cílové databáze něbo nějaké in-memory varianty? Podělte se o své názory a zkušenosti v diskuzi pod článkem. Pokud přemýšlíte o tom, jak vytvořit a spravovat datový model pro testy, můžete se podívat na můj článek o nástroji LiquiBase. Pokud řešíte inicializaci dat pro testy, můžete některé odpovědi nalézt v článku o inicializaci databázových dat.

Verzování datového modelu a LiquiBase

Přidávání tabulek, sloupců, integritních omezení, přejmenovávání a štěpení tabulek, konfigurace vývojového, testovacího a produkčního prostředí... Je mnoho požadavků, které mají vliv na podobu datového modelu. V tomto blogu zkusím popsat běžné činnosti týkající se správy relačního datového modelu a stručně představit nástroj LiquiBase. Článek je volným pokračováním předchozího příspěvku Inicializace databázových dat prostředky Javy.

Různá prostředí kladou na správu datového modelu různé nároky - přizpůsobitelnost, nezávislost na konkrétní databázi, použitelnost pro testy nebo verzování. Krátce jsem je popsal v předchozím příspěvku. Jaké jsou běžné činnosti, které se správou datového modelu souvisí? Samozřejmě potřebujeme evidovat jakékoliv změny formou nějakého changelogu. V jistou chvíli je nutné změny z changelogu aplikovat na nějaký existující model - provést jeho aktualizaci. Někdy může být nutné naopak změny odstranit - provést jejich rollback. Při kvapném rozvoji datového modelu přijde vhod možnost porovnat dva modely. Při zavádění verzování je užitečná možnost reverzního vytvoření changelogu z existující databáze. A v neposlední řadě je dobré mít změny dobře zdokumentované.

Právě na tyto činnosti se zaměřili tvůrci nástroje LiquiBase. Než se k němu ale dostanu, popíšu napřed alternativní možnosti. Změny datového modelu se tradičně dají organizovat pomocí sql skriptů verzovaných nějakým scm nástrojem (jako je třeba Subversion). Pro každou změnu datového modelu se připraví samostatný sql skript, který se prostě vloží do scm systému. Jeho revize potom dovolí vybrat správnou množinu skriptů, které někdo ručně spustí. Některé firmy nedají dopustit na nástroje, které si vyvinuly svépomocí a které dovolí správu modelu alespoň částečně automatizovat. I správa datového modelu je doménou, na které se dá vydělávat a kterou řeší komerční nástroje.

LiquiBase

Na nových projektech se snažím používat LiquiBase. Je to nástroj, který mě zaujal svým úzkým zaměřením (neřeší nic, co by se správou datového modelu nesouviselo), snadnou přístupností (začlenění do vývojového procesu je jednoduché a přímočaré) a perfektní dokumentací. Nebudu suplovat dokumentaci LiquiBase a tutoriály přístupné z jeho webu, chci nástroj jenom stručně představit.

Changelog

Klíčový konceptem je changelog - xml soubor obsahující změny, zvané changesety. Změnou je třeba založení tabulky, přidání sloupce nebo vytvoření indexu. Každá změna je identifikovaná dvojicí (id,author). Changelog představuje historii změn datového modelu, ale neříká nic o tom, jak vypadají konkrétní instance modelu. Proto LiquiBase potřebuje, aby každý spravovaný mode obsahoval tabulku DatabaseChangeLog(id,author,filename,dateexecuted,...), která eviduje changesety aplikované na model.

Příklad changelogu:

<databaseChangeLog

  xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.6"

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.6

         http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.6.xsd">

    <changeSet id="1" author="bob">

        <createTable tableName="department">

            <column name="id" type="int">

                <constraints primaryKey="true" nullable="false"/>

            </column>

            <column name="name" type="varchar(50)">

                <constraints nullable="false"/>

            </column>

            <column name="active" type="boolean" defaultValue="1"/>

        </createTable>

    </changeSet>

</databaseChangeLog>

Changelog neobsahuje identifikaci databáze nebo chcete-li dialektu. Ten se zadává až při spouštění update a rollback příkazů. Pokud nemáme příliš specifické požadavky, můžeme tedy jeden changelog použít např. pro testovací MySQL nebo produkční Oracle. Vedle předdefinovaných příkazů mohou changesety obsahovat i sql skripty nebo odkazy na ně. 

Podporované jsou tyto databáze:

• MySQL, PostgreSQL, Oracle, MS-SQL, Sybase Enterprise, Sybase Anywhere, DB2, Apache Derby, HSQL, H2, InterSystems Caché, Firebird, MaxDB / SAPDB, SQLite.

A tyto předdefinované operace (refactorings):

• Structural Refactorings - Add Column, Rename Column, Modify Column, Drop Column, Alter Sequence, Create Table, Rename Table, Drop Table, Create View, Rename View, Drop View, Merge Columns, Create Stored Procedure
• Data Quality Refactorings - Add Lookup Table, Add Not-Null Constraint, Remove Not-Null Constraint, Add Unique Constraint, Drop Unique Constraint, Create Sequence, Drop Sequence, Add Auto-Increment, Add Default Value, Drop Default Value
• Referential Integrity Refactorings - Add Foreign Key Constraint, Drop Foreign Key Constraint, Add Primary Key Constraint, Drop Primary Key Constraint
• Architectural Refactorings - Create Index, Drop Index
• a další

LiquiBase je možné používat i na nepodporované databázi. Pokud pro ni nefungují některé z předdefinovaných operací, může changeset jednoduše obsahovat specifický sql kód.

Changelog můžeme udržovat ručně, vytvořit reverzně z existujícího modelu nebo použít podporu v IDE. Dobře funguje plugin pro IntelliJ IDEA a deklarovaná je i podpora pro Eclipse. Plugin pro Eclipse se mi ale nepodařilo zprovoznit.

Update a rollback

Základní příkazy pro aplikaci, resp. mazání změn, jsou update a rollback. Spouští se z příkazové řádky, z mavenu, z antu nebo třeba z IDE. Příkaz update aplikuje všechny nové changesety na existující model. To, jestli je daný changeset nový nebo již aplikovaný, pozná podle záznamů v tabulce DatabaseChangeLog. Příkaz rollback bere jako vstupní parametr identifikaci changesetu a všechny novější změny z modelu odstraní (pokud je to možné).

Dalšími užitečnými funkcemi jsou například

• Diff - porovnání dvou databází a vytvoření changelogu.
• DBDoc - vytvoří html manuál s popisem všech změn datového modelu.
• nebo SQL výstup, který changlog převede na SQL skript.

Alternativy

migrate4j nebo dbmigrate jsou nástroje s podobným zaměřením jako LiquiBase. Vývojáři Ruby asi budou znát Ruby Migrations. 

Shrnutí

Článek chtěl popsat požadavky na evidenci změn datového modelu a ukázat, že s LiquiBase lze s malým úsilím změny organizovat lépe než jako "skripty v svn". Jak změny datového modelu organizujete vy? Máte bližší zkušenosti s nástrojem LiquiBase nebo jiným podobným? Podělte se o své názory v diskuzi pod článkem a zapojte se do hlasování.