A Hibernate az egyik legrégibb, legelterjedtebb és legfejlettebb ORM framework Java-hoz. Az a nagyon jó benne, hogy az ember simán le tudja mappolni vele entitásainak 95%-át. És az a nagyon rossz, hogy a maradék 5%-kal órákat, napokat lehet szívni.

A szívás aktuális tárgya a következő probléma: A és B osztály 1-N relációban áll egymással, tehát A-ban van egy Collection<B> típusú property, B-ben pedig egy A típusú. A Hibernate-et az viccelte meg, hogy a B-ben az A típusú property nem B-ben, hanem annak ősosztályában, C-ben volt deklarálva. Na de inkább nézzünk kódot:

@Entity
class C {
@ManyToOne
private A a;
}

@Entity
class B extends C {
}

@Entity
class A {
@OneToMany(mappedBy = "a")
private Collection<B> b;
}

Tehát itt a @OneToMany annotációra kivételt dobott, mondván hogy a B osztályban nincs "a" nevű property. A problémára én nem nagyon találtam megoldást, amit mégis azt azért leírom. Az egyik lehetőség nyilván az, hogy a "b" property-t @Transient-ként annotáljuk, de így a hibernate nem fogja fetch-elni, ezt manuálisan kell megcsinálni (szerintem ez elfogadható kompromisszum). A másik, hogy a C-t @Entity-vel és @MappedSuperclass-szal egyaránt annotáljuk. Iyenkor a single table inheritance ugrik, (más inheritance mapping-ot nem próbáltam) tehát nagyon érdemes megfontolni, hogy milyen teljesítményveszteséggel jár ez a megoldás, és hogy ez nekünk mennyire probléma.

Egyébként a hibernate team szerint ez nem bug, hanem feature, de hogy miért azt nem sikerült megtudnom. Állítólag van valahol egy fórum post, ahol alaposan el van magyarázva hogy miért így (nem) működik a dolog, de ezt nekem nem sikerült megtalálni. Ha valakinek sikerül, akkor kommentbe kérek linket :)

A Neo4j egy java-ban írt és java programokhoz használható beágyazott adatbázis-motor, mely attól speciális, hogy a legtöbb adatbázistól eltérően nem a relációs adatmodellt követi, hanem hálózat-alapú, tehát objektumhálót tárol. Ez azért nagyon jó elvileg, mert így az ember megspórolhat egy komplex ORM frameworköt az alkalmazásából (mint pl. Hibernate), mivel így a futásidejű (tranziens) és a perzisztens adatreprezentáció nem tér el egymástól gyökeresen. A Neo4j teljesen tranzakció-alapú, tehát csak egy tranzakción belül végezhetünk műveleteket az objektumhálónkon. Ez a háló egy irányított gráf, melyben minden csomóponthoz és kapcsolathoz tulajdonságokat (kulcs-érték párokat) rendelhetünk. A csomópont és a kapcsolat osztályok a Neo4j API részét képezik, tehát magát az entitásaink között kialakult hálót nem menthetjük el a Neo4j adatbázisunkba, hanem le kell képeznünk az API által nyújtott háló-szerkezetre, ezt azonban könnyen megtehetjük a DAO-rétegben.

A Neo4j egyébként sajnos csak ingyenes termékek fejlesztéséhez ingyenes, és egy gyors guglizás során nem is találtam semmilyen alternatívát, pedig hatékony eszköznek tűnik. Persze így egy egyszerű pilot után még nem mernék komoly fejlesztést a Neo4j-re alapozni... :)

A Doctrine egy php-ben írt ORM framework, mostanában többek közt ezzel dolgozom. Mikor először hallottam róla mondom tökjó, épp ideje volt, egy ilyen cuccra általában szüksége lehet _komoly_ php-s webalkalmazás fejlesztésekor (persze az ORM frameworkök általában elég lassúak, úgyhogy azért meg kell gondolni hogy van-e akkora a projekt hogy szükség legyen rá). Javához a hibernate/jpa nagyon jó (legalábbis nekem bejött, még akkor is ha néha szopás van vele), úgyhogy korábban jó tapasztalataim voltak az ORM-mel.

Sajnos hamar kiderült, hogy a doctrine egyáltalán nem kiforrott, nem tud túl sokal és nagyon bugos. Vannak - nem triviális, de azért nem is túl bonyolult - lekérdezések, melyeket rosszul generál le, van olyan, hogy valami rossz paraméter esetén egy jól elhelyezett die(); utasítással leállítja az egész kérést (nagyon jó így hibát keresni, hogy nem mondja meg mibaja), csomó mindent nem tud magától kezelni. Igazából nem is lenne ezzel baj, mert minden projektnek van ilyen állapota, csak nem tudom hogy ezt így miért kellett mint 1.0-ás verziót kiadni.

Persze nyílt kódú projekt, ha nagyon akarnék be is szállhatnék, általában érdekelnek az ORM frameworkök, használom is őket, úgyhogy nem kizárt hogy be fogok szállni valamennyire :) Egyébként nagyon dicséretes, hogy a fejlesztők januárban kiadtak egy egész jó, részletes és könnyen olvasható 320 oldalas ebookot a Doctrine-ről (letölthető a projekt honlapjáról).