Ujorm verze 1.32

Byla uvolněna nová verze Ujorm 1.32 obsahující nové Validátory a v modulu ORM možnost načtení relačních databázových tabulek jediným SQL dotazem. Více informací je v anglické verzi tohoto oznámení.

Generátor getterů pro NetBeans

V repozitáři SourceForge je připraven ke stažení nový open-source pluggin určený pro IDE NetBeans 7.2, který slouží pro generování getterů a setterů UJO objektů podle jeho Klíčů. Pro ilustraci přikládám několik screenshotů:

1. Pro instalaci plugginu je třeba nejdříve stáhnout soubor typu "nbm" ze SourceForge do lokálního adresáře a pomocí NB-Pluggin manageru nainstalovat:

2. Nový pluggin pak najdeme v kontextovém menu, které se používá také pro generování getterů a setterů běžných JavaBeans:

3. Dialog umožňuje vybrat klíče, pro které se mají vytvořit gettery a settery. Poslední volba dole pod seznamem klíčů umožňuje zkopíruje také JavaDoc:

4. Výsledek: generovaný kód se bude podobat následující ukázce:

Za tento pluggin patří poděkování jeho autorovi Martinovi Mahrovi.

Pokyny k migraci do Ujorm 1.30

Pokud zvažujete migraci do Ujorm 1.30, doporučuji použít tři jednoduché kroky:

1. v Maven projektech upravte závislost na: groupId=org.ujorm + version=1.30
2. nahraďte všechny texty "UjoProperty" za cílové "Key" ve vašem projektu a
3. opravte použití metod označených jako @Deprecated

Volitelně lze nahradit použití statických továrních metod pro tvorbu klíčů za vhodnější použití třídy KeyFactory.

Doplněno 09.12.2012: po zkušenostech s několika projekty doporučuji porovnat popisy perzistentního meta-modelu před a po migraci. Úplný popis meta-modelu ve formátu XML se zapisuje do logu aplikace vždy po startu ORM. Pokud bude migrace  ok, budou obě verze identické. Tímto přístupem lze odhalit nejen překlepy v názvech klíčů UJO objektu.

Ujorm verze 1.30

Po delší přestávce byla uvolněna verze Ujorm 1.30, která obsahuje několik důležitých změn v API, kde na prvním místě je třeba zmínit přejmenováni původního interface UjoProperty za nový název Key. Ten původní interface zůstal zachovaný jako @Deprecated, názvy implementačních tříd zůstávají. Důvody byly následující:

• původní název UjoProperty byl trochu zavádějící a pro jeho neměnnou vlastnost a tak občas bylo obtížnější vysvětlit jeho význam. Nový název vychází z běžného pojmenování parametrů interface java.util.Map .
• původní název byl dlouhý a tím hůře čitelný ve zdrojovém kódu
• v poslední době vzniklo několik nových tříd, které se od názvu klíče (Property) odvíjí a bylo užitečné toto rozhodnutí urychlit, jedná se konkrétně o třídy KeyRing a KeyFactory.

Nový KeyRing slouží jako serializovatelná kolekce klíčů - protože klíče samy o sobě serializovatelné být nemohou - přišly by totiž o vlastnost unikátní instance v rámci class-loaderlu. Potřeba serializovat klíče může být v některých případech nezbytná, konkrétní příklad využití je ve Wicket frameworku.

Další nová třída třída se jmenuje KeyFactory a je určena k výrobě objektů typu Key. Výhodou továrny je, že ji lze použít i pro statické konstanty nějakého Interface. Užitečnou vlastností může být automatický tvorba názvu klíčů podle názvu jeho fieldu s volitelnou možností konverze jména na camel-case. Nově také není potřeba při tvorbě klíče posílat jeho datový typ parametrem, framework umí tento atributy získat z meta-modelu fieldů v době uzamčení továrny (případně při prvním načtení klíčů). Každý takový klíč obsahuje teď nový atribut své doménové třídy. Ukázka použití:

public class Person extends AbstractUjo {
  private static final KeyFactory f = newFactory(Person.class);
   
  public static final Key<Person,String > NAME = f.newKey();
  public static final Key<Person,Boolean> MALE = f.newKey();
  public static final Key<Person,Double > CASH = f.newKey();
   
  @Override public KeyList<?> readKeys() {
    return f.getKeys();
  }
}

Framework nabízí nový, zjednodušený klíč zvaný WeakKey, který neobsahuje doménový generický parametr. Jeho využití se nabízí jako náhrada konstant pro práci s objekty typu Map, List, případně pro čtení parametrů z objektu HttpRequest, kde provádí konverzi na požadovaný typ. Instance se pak vytváří pomocí WeakKeyFactory.

Framework je možné připojit do Maven projektu pomocí závislosti:

<dependency>
    <groupId>org.ujorm</groupId>
    <artifactId>ujo-core</artifactId>
    <version>1.30</version>
</dependency>

a pro případ využití ORM:

<dependency>
    <groupId>org.ujorm</groupId>
    <artifactId>ujo-orm</artifactId>
    <version>1.30</version>
</dependency>


Pro použití UJO objektů ve frameworku Wicket bude potřebná implementace třídy KeyModel, která je analogií ke standardní implementaci Wicket třídy PropertyModel. Třídu je možné získat pomocí závislosti:

<dependency>
    <groupId>org.ujorm</groupId>
    <artifactId>ujo-wicket/artifactId>
    <version>1.30</version>
</dependency>

Tento modul neobsahuje rozsáhlé služby, přesto přikládám pro inspiraci vytvoření jednoduché tabulky:

 List<ICellPopulator> columns = KeyPopulator.list
    ( Employee.ID
    , Employee.FIRSTNAME
    , Employee.LASTNAME
    , Employee.ADDRESS.add(Address.CITY)
    );

 final WebMarkupContainer table = new WebMarkupContainer("table");
 final DataGridView grid = new DataGridView("gridPanel", columns,
       new  InnerPeopleProvicer());
 table.setOutputMarkupId(true);
 grid.setItemsPerPage(20);
 add(table);
 table.add(grid);
 add(new AjaxPagingNavigator("tableNavigator", grid));

Za významnější změny API se všem uživatelům frameworku omlouvám, změny však byly nezbytné pro další rozvoj této knihovny.

V případě zájmu lze najít více informací najít v

• dokumentaci Ujorm-Core
• dokumentaci Ujorm-ORM
• home page
• popis změn

Uvolnění Ujorm 1.21

Změny poslední verze:

• podpora Java 7
• je možné sestavovat vlastní SQL dotazy za běhu programu pro komplikované požadavky
• přímá podpora logovacího frameworku Slf4J
• drobná rozšíření API pro snadnější použití
• nový interface pro jednodušší ukládání dat do BLOBu
• implementace abstraktního doménového objektu pro bezpečné vícevláknové operace
• řada drobných vylepšení a
• oprava menších chyb v dialektech i jádru frameworku

Úplný popis změn je v angličtině tady.

Ujorm verze 1.20

Vyšla nová verze Ujorm 1.20, hlavní změny jsou:

• projekt dostal novou doménu: http://ujorm.org/
• je implementovaná podpora dávkových příkazů pro INSERT a UPDATE
• v příkazu SELECT je možné požadovat pouze vybrané sloupce tabulky pro lepší výkon dotazů
• podpora pro nové klíčové slovo DISTINCT v příkazu SELECT
• vybrané tabulky mohou být označeny jako READ-ONLY pomocí nového parametru v anotaci  @Table
• byla doplněna dokumentace v angličtině Ujorm User Guide
• na home page byly doplněny nové referenční projekt

Další informace naleznete v Release notes.

Ujorm verze 1.10

Vyšla nová verze Ujorm frameworku pro mapování objektů na relační databázi. Mezi hlavní novinky patří:

• nový dialekt pro databázi MS-SQL díky Tomášovi Hamlovi z firmy Effectiva
• podpora tzv Native Criterion pro vkládání podmínek obsahující SQL výrazy
• anotace @Comment umožňuje popisovat databázové sloupce a tabulky
• významně rozšířená dokumentace Ujorm User Guide.
• nový výkonnostní test nad databází H2
• ve verzi 1.00 nebyly objeveny žádné kritické chyby

Úplný seznam změn je dostupný v angličtině tady.

Vyšel Ujorm verze 1.00

K dispozici je nová verze open-source ORM frameworku Ujorm 1.00  navrženého pro rychlý vývoj Java aplikací nad relační databází. V posledním roce vývoje frameworku mnoho změn reagovalo na reálné potřeby vývojářů komečních aplikací. Mezi hlavní novinky patří:

• řízení session a transakcí pomocí Spring frameworku
• optimalizace performace a rozšířené API
• doplněná dokumentace
• pozitivní ohlasy z produkčního nasazení

V současné době probíhá vývoj několika dalších nových projektů založených na ORM frameworku Ujorm. Vzkaz od vývojářů zní: “Ujorm se nám osvědčil a počítáme s ním i pro další projekty”.

Odkazy:

• Inteview o zkušenostech s Ujorm na produkčním prostředí
• Ujorm User Guide
• Home Page

Interview s technickým ředitelem firmy Effectiva o použití Ujorm

ORM framework Ujorm má svoji instalaci na produkčním prostředí. Se souhlasem technického ředitele firmy Effectiva přináším krátké interview o zkušenostech při vývoji a nasazení aplikace postavené na Ujorm:

Q: Zdravím Radku, můžeš říct pár slov o sobě ?
A: Ahoj, jmenuji se Radek Majer a jsem technickým ředitelem ve společnosti Effectiva Solutions s.r.o., která se zabývá především vývojem software. Ve volném čase hraji hokej.

Q: Můžeš představit vaši aplikaci eCall postavenou na Ujorm ?

A: eCall představuje kompletní softwarové vybavení pro moderní call centrum, nejedná se tedy o jednu aplikaci. Ovšem srdcem celého řešení je aplikace komunikující s telefonní ústřednou postavená na Ujormu. Úloha této aplikace je kritická, závisí na ní běh celého systému, často nepřetržitě 7 dní v týdnu - proto ji přirovnáváme právě k srdci.

Q: Jaká byla tvoje role na projektu ?
A: Jsem odpovědný, mimo jiné, za vhodné použití technologií nejen u nás ve firmě ale i v realizovaných projektech. Vývojáři rádi upřednostňují zajímavé či populární nástroje před efektivním. Je třeba jim dát určitou volnost, ale na druhé straně trvat na pragmatickém řešení.

Q: Proč jste použili Ujorm na místo nějakého standardního ORM frameworku?
A: Často jsem od vývojářů slyšel nářky na Hibernate. Vývoj v tomto ORM měl k efektivnímu daleko i přes všechny vymoženosti, které Hibernate nabízí. Nejprve jsme hledali problém ve špatném používání, ale nakonec jsme společně dospěli k názoru, že celý framework je prostě příliš komplikovaný a na velkém projektu je udržení stabilní ORM vrstvy příliš nákladné. Hledali jsme tedy v základu jednoduchou alternativu a po zvážení všech kandidátů jsme vybrali Ujorm.

Q: Kolik používá aplikace databázových tabulek ?
A: Desítky. Ale zajímavější je spíše množství záznamů, se kterým se musí aplikace vypořádat. Představte si 50 operátorů, kteří aplikaci používají v reálném čase. Pro zpracování statistik jsou pak přepočítávány miliony záznamů.

Q: Můžeš zveřejnit nějaké statistiky při reálné zátěži aplikace?
A: Přesná čísla nemám k dispozici, ale reálné potřeby se ukázaly ještě vyšší než původní odhady. Nenarazili jsme na žádné zdržení na ORM vrstvě. Ujorm se se zátěží vypořádává výborně.

Q: Jaké problémy jste řešili při použití Ujorm ?
A: Nutnost použít UJO jako business objects. Všichni jsou dnes zvyklí na POJO a UJO jsou prostě jiné. Ale výhody, které architektura UJO poskytuje tuto počáteční nechuť dokonale překonaly.

Q: Přinesl Ujorm nějaké výhody pro váš projekt ?
A: Ano, dovolím si tvrdit, že nejen rychlejší vývoj, ale zejména mnohem lepší další udržovatelnost produktu do budoucna.

Q: Použijete Ujorm i do nových projektů ?
A: Ano, zejména nemáme důvod se vracet k Hibernate.

Q: Co by jsi vzkázal vývojářům, kteří zvažují Ujorm použít ?
A: Myslete :)
Q: Děkuji za rozhovor.