https://blog.root.cz/ https://i.iinfo.cz/r/rss-88x31.gif 88 31 https://blog.root.cz/ RSS názorů ze všech blogů serveru Root.cz cs Sun, 31 May 2026 06:49:51 GMT https://blog.root.cz/ponec/ujorm3-final/#o1305729?utm_source=rss&utm_medium=text&utm_campaign=rss K dispozici je nová verze 3.0.3. Ve třídě SelectQuery je opraveno generování příkazu SQL INSERT při použití třetí řetězené relace v kombinaci s LEFT JOIN. Opravena byla také implementace metody pro negaci podmínek typu Criterion. Nová verze výrazně zrychlila operace typu INSERT v případech, kdy není třeba získávat generovaný klíč ID, což má pozitivní vliv zejména na výkonnostních testech PostgreSQL. Knihovna nyní automaticky načítá konfiguraci logování ze souboru ujorm-config.properties, díky čemuž se SQL dotazy v JUnit testech vypisují do terminálu bez jakéhokoliv dodatečného nastavení. Pavel Ponec Sun, 31 May 2026 06:49:51 GMT blog.root.cz-blogComment-1305729 https://blog.root.cz/ponec/ujorm3-final/#o1304475?utm_source=rss&utm_medium=text&utm_campaign=rss Pokud je třeba při mapování vytvářet relační objekt bez ohledu na null hodnoty, je třeba přidat identifikátor. Pavel Ponec Tue, 26 May 2026 12:47:37 GMT blog.root.cz-blogComment-1304475 https://blog.root.cz/ponec/ujorm3-final/#o1304466?utm_source=rss&utm_medium=text&utm_campaign=rss > Jak se zachová mapování, když volitelná relace (optional) nevrátí žádná data? Při mapování platí obecné pravidlo: pokud žádný sloupec z připojené tabulky nenese nenullovou hodnotu, hostitelský objekt se nevytvoří — příslušné pole zůstane null. Toto chování je nyní zdokumentováno v JavaDoc třídy ResultSetMapper v sekci Null-object Rule. Načítání přes řetězec vztahů mandatory optional se tedy chová přirozeně: povinná strana se vždy vyřeší, zatímco volitelná strana vrátí null, pokud neexistuje odpovídající záznam — tedy když LEFT JOIN vrátí pro danou tabulku samé nullové hodnoty. Pavel Ponec Tue, 26 May 2026 12:43:06 GMT blog.root.cz-blogComment-1304466 https://blog.root.cz/ponec/ujorm3-final/#o1304133?utm_source=rss&utm_medium=text&utm_campaign=rss Mate pravdu. Diky za opravdove porovnani. Dalibor Petras Mon, 25 May 2026 00:24:50 GMT blog.root.cz-blogComment-1304133 https://blog.root.cz/ponec/ujorm3-final/#o1304058?utm_source=rss&utm_medium=text&utm_campaign=rss Myslím, že těch rozdílů je víc než jedna. Ujorm3 generuje při kompilaci (APT procesor) typované Meta třídy s Key<Employee, City> deskriptory – chybný název sloupce nebo špatný typ parametru se odhalí ihned při kompilaci, nikoli za běhu v produkci. JDBI SQL Object API přináší určitou typovou bezpečnost přes anotované rozhraní, ale samotné názvy sloupců a cesty k atributům zůstávají řetězce. Z toho plyne i druhý rozdíl: SelectQuery generuje FROM a JOIN klauzule automaticky podle cest v metamodelu ( MetaEmployee­.city, MetaCity.name), takže JOIN není potřeba psát ručně. Metoda columns() pak vygeneruje výčet všech sloupců primární tabulky přímo z metamodelu – v JDBI lze sice použít select("*"), ale jde o prostý řetězec bez typové vazby. Třetí věc je typově bezpečný Criterion pro WHERE klauzule – podmínky se skládají programově jako binární strom objektů, ne jako SQL fragmenty. Čtvrtý bod: partial UPDATE – jde buď explicitně předat sadu Key objektů označující sloupce k aktualizaci, nebo poslat původní objekt a Ujorm3 si seznam změněných sloupců odvodí porovnáním sám; v JDBI obojí vyžaduje ruční SQL. Za páté, Java Records jsou podporovány jako first-class citizen včetně automatického mapování M:1 relací. Za šesté, na PostgreSQL jsou výsledky smíšené: Ujorm3 vede v operacích UPDATE a paměťové efektivitě, zatímco JDBI je rychlejší například u batch insertu nebo čtení entit; na H2 Ujorm3 konzistentně vyhrává prakticky ve všech metrikách. A za sedmé, Ujorm3 nemá žádné externí závislosti a jeho JAR má velikost 0,27 MB, což je přibližně pětina velikosti JDBI (1,34 MB); obě hodnoty jsou měřeny bez JDBC driveru. JDBI samozřejmě vyhrává šíří ekosystému – pluginy pro Guava, Spring, Vavr, lepší pokrytí stored procedures a větší komunita. Anotované DAO rozhraní ve stylu Feign jsou pohodlná věc. Ale „stejné výhody" to není – záleží hodně na tom, jak moc vadí, když se chyba v dotazu projeví až za běhu. Pavel Ponec Sun, 24 May 2026 12:34:51 GMT blog.root.cz-blogComment-1304058 https://blog.root.cz/ponec/ujorm3-final/#o1304040?utm_source=rss&utm_medium=text&utm_campaign=rss Ja ted pouzivam JDBi v komercnim projektu tak jsem rychle porovnal pro a proti s Ujorm. Nasel jsem jedinou vyhodu Ujorm v deklaraci schema pomoci entit. Pokud tohle nepotrebujute, a schema definuje nekdo jiny, zvolil bych JDBi ktery ma stejne vyhody a navic muzete psat DAOs pomoci anotovanych interface. (neco jako Feign client) Dalibor Petras Sun, 24 May 2026 11:14:06 GMT blog.root.cz-blogComment-1304040 https://blog.root.cz/ponec/ujorm3-final/#o1302852?utm_source=rss&utm_medium=text&utm_campaign=rss Přikládám odkaz na jiné zpracování stejného tématu, tentokrát v angličtině: https://dev.to/pponec/native-sql-in-java-without-jdbc-boilerplate-meet-ujorm3-3ab2 Pavel Ponec Tue, 19 May 2026 13:30:09 GMT blog.root.cz-blogComment-1302852 https://blog.root.cz/ponec/ujorm3-rc1/#o1285200?utm_source=rss&utm_medium=text&utm_campaign=rss Je pravda, že QueryDSL SQL je architektonicky frameworku Ujorm3 podobný. Obě knihovny obcházejí komplexní standard JPA, operují těsně nad úrovní JDBC a využívají silnou typovou kontrolu nad databázovým schématem. Rozdíl spočívá v jejich primárním zaměření. QueryDSL SQL exceluje v typové bezpečnosti a umožňuje sestavování složitých dotazů čistě přes Java API. Ujorm3 naproti tomu maximalizuje propustnost a minimalizuje paměťovou alokaci (tlak na Garbage Collector), čehož dosahuje (mimo jiné) delegováním složitějších relačních dotazů s JOINy na nativní SQL. Zvolená architektura se odráží v naměřeném výkonu. Jak ukazují výsledky doplněného benchmarku, Ujorm3 je při hromadném zápisu (Batch Insert) téměř čtyřikrát rychlejší a generuje zhruba čtvrtinovou zátěž na paměť ve srovnání s QueryDSL. Výrazný náskok Ujorm3 se potvrzuje i při dynamické aktualizaci dat (Random Update), kde QueryDSL vyžaduje více než dvojnásobný čas i paměťovou alokaci. Při čtení dat s relacemi (Read With Relations) dosahují obě knihovny srovnatelných výsledků, přičemž Ujorm3 zůstává mírně rychlejší a úspornější. Z pohledu programátorské ergonomie Ujorm3 zásadně redukuje množství opakujícího se rutinního kódu. Na rozdíl od QueryDSL SQL, kde se každý příkaz musí explicitně sestavit (včetně ručního výběru sloupců pro částečný UPDATE), poskytuje Ujorm3 vestavěné CRUD operace a automatickou detekci změn (dirty checking) pomocí snapshotů entit. Zatímco QueryDSL SQL nabízí vývojáři stoprocentní kontrolu nad strukturou dotazu přímo v Javě bez psaní textových řetězců, Ujorm3 přináší vyšší produktivitu a hardwarovou efektivitu při běžných databázových operacích. Pavel Ponec Mon, 23 Mar 2026 18:01:12 GMT blog.root.cz-blogComment-1285200 https://blog.root.cz/ponec/ujorm3-rc1/#o1285164?utm_source=rss&utm_medium=text&utm_campaign=rss Bolo by nejaké porovnanie s JOOQ, či QueryDSL poruke? To mi príde viac porovnateľné, ako s JPA implementáciami... Alebo spring-data. Ten má imho používanie rovnako jednoduché ako táto knižnica. Vrámci porovnania sú (pre mňa, ako programátora) dôležité aj jednoduchosť, nielen výkon Prípadne do squirrel-sql existoval plugin, ktorý z DB tabuliek vedel generovať pekné POJO s metódou, ktorá vedela parsovať dáta z resultsetu z jdbc... To bolo ale ešte menej, ako táto knižica. Teda, asi porovnanie s tímto by nemalo zmysel. V každom prípade pekné a použiteľne vypadajúce. Ďakujem za info. Křestní Příjmení Mon, 23 Mar 2026 15:42:28 GMT blog.root.cz-blogComment-1285164 https://blog.root.cz/ponec/ujorm3-rc1/#o1284996?utm_source=rss&utm_medium=text&utm_campaign=rss Doplňuji, že tento přístup není v Java světě novinkou. Pro dosažení maximálního výkonu generují bajtkód za běhu i prověřené knihovny jako HikariCP, Jackson (modul Afterburner) a v neposlední řadě i proxy mechanismy ve Springu. Pavel Ponec Mon, 23 Mar 2026 09:34:16 GMT blog.root.cz-blogComment-1284996