[Hibernate] Ervaringen

[-FoX-]

Object relational mapping wordt gebruikt om object georienteerde objecten naar een relationele database te mapping. Hibernate is een tool die voorziet in dergelijke mapping.

Op deze manier zal de programmeur niet meer afhankelijk zijn van de relationele database, maar kan hij zich volledig baseren op het OO gedeelte. Hibernate doet de rest. Zelfs het genereren van DDL is mogelijk adh van hibernate.
Op deze manier kan je een applicatie creëren die niet meer afhankelijk is van de rdbms.

Hibernate geniet mijn voorkeur omdat het een van de meest volwassen orm tools is die op de markt zijn en voorziet bovendien een goede documentatie.

Ik ben een beginner als het om Hibernate gaat, maar ik zou graag wat gebruikerservaringen, zowel positief als negatief, te horen krijgen.

Tot nu toe bevalt hibernate mij zeer goed en ben dan ook nog geen gekke dingen tegen gekomen, al sluit ik niet uit dat deze wel kunnen voorkomen.

Als je meer wil te weten komen over Hibernate, bezoek dan hun website even

[Verwijderd]

Zeer interessant, alleen het eerste wat me opviel was For Idiomatic Java, da's wat jammer want ik doe alleen delphi & progress. Ga wel eens even die site doorspitten.
Denk dat een aantal collega's hier wel interesse in hebben.

[reddog33hummer]

Het ziet er een beetje uit als een XML-Database.
Het enigste verschil is dat je echte objecten hebt i.p.v. geparste objecten.
Dit geeft wel een probleem. Concurancey. Zodra je met meerdere threads gaat werken en het systeem tussen een transactie neer kan ploffen gaat het leuk worden met objecten. Er kunnen namelijk transacties zijn binnen in je code. dat is hiermee niet af te vangen.

Ik denk dat voor de meeste zaken een XML-RDB mischien een verstandiger keuze is. Dat neemt niet weg dat dit voor een aantal zaken meer geschikt is.

[Creepy]

reddog33hummer schreef op 13 mei 2004 @ 10:41:
Het ziet er een beetje uit als een XML-Database.
Het enigste verschil is dat je echte objecten hebt i.p.v. geparste objecten.
Dit geeft wel een probleem. Concurancey. Zodra je met meerdere threads gaat werken en het systeem tussen een transactie neer kan ploffen gaat het leuk worden met objecten. Er kunnen namelijk transacties zijn binnen in je code. dat is hiermee niet af te vangen.

Wat bedoel je hiermee precies? "Leuk worden met objecten?". En een geparst object is toch ook een echt object?
Het doel van deze tool is juist om met Objecten te kunnen werken zonder je bezig te houden met de databaselaag.

Welke problemen zie je hierin?

Ik denk dat voor de meeste zaken een XML-RDB mischien een verstandiger keuze is. Dat neemt niet weg dat dit voor een aantal zaken meer geschikt is.

Nou zie ik weinig problemen in jou omschrijving, maar zou je kunnen aangeven WAAROM een XML-RDB een betere keuze zou zijn? Want de gemiddelde XML database is stukken trager met veel data dan een "echt" RDBMS (inclusief het gebruik van software als Hibernate)

[ Voor 4% gewijzigd door Creepy op 13-05-2004 10:54 ]

[Alarmnummer]

reddog33hummer schreef op 13 mei 2004 @ 10:41:
Het ziet er een beetje uit als een XML-Database.

Hibernate is een object relationeel mapping tool. Het is geen database en valt ook niet te vergelijken met een database. Je zult er zelf nog een sql database achter moeten plakken.

Het enigste verschil is dat je echte objecten hebt i.p.v. geparste objecten.

Wat is het verschil? Als de data nou komt uit een serialized stream met bytes, komt uit een rdbms of iets iets anders. Als de objecten maar ergens uit onstaan.

Dit geeft wel een probleem. Concurancey.

Concurrency. En daar heb je transacties voor. Je kunt op je transactie (van de db) instellen wat voor vorm van concurrency control je wilt toepassen.

Zodra je met meerdere threads gaat werken en het systeem tussen een transactie neer kan ploffen gaat het leuk worden met objecten.

Hibernate ondersteunt de 'unit of work' pattern. Waarmee je alle acties op objecten of allemaal kunt laten slagen, of allemaal terug kan laten zetten (de A van Atomic uit ACID)

Ik denk dat voor de meeste zaken een XML-RDB mischien een verstandiger keuze is. Dat neemt niet weg dat dit voor een aantal zaken meer geschikt is.

Wat maakt het uit wat voor persistence medium je gaat gebruiken? Als het zich maar houd aan de ACID eigenschappen dan zit het wel snor. Dat XML databases misschien praktischer zijn voor sommige toepassing is een 2e.

[BoomSmurf]

Heb geen ervaring met Hibernate, maar kan het principe wel, Bold for Delphi is ook zoiets. Ik moet zeggen dat ik daar erg van onder de indruk ben, werkt superfijn, alleen deployen is niet altijd even makkelijk maar dat ligt aan het pakket. Ik zal ook eens naar Hibernate gaan kijken.

[-FoX-]

Nog maar eens een shopje.

Het verbaasd me echter wel dat er zo weinig mensen ervaringen hebben met ORMtools. Of is het dat schijn bedriegt?

[zneek]

Wij hebben ook wel eens een project met Hibernate gedaan. Na een redelijke tijd in het project hebben we toch besloten om over te stappen op EJB CMP. Je kunt met Hibernate hele nette oplossingen bouwen, maar je moet dan nog redelijk wat zelf "regelen", wat in EJB CMP al voor je geregeld is. Tot op zekere hoogte een kwestie van keuze, ik ken mensen die diep gelukkig zijn met Hibernate, maar wij werken nu al weer een tijdje met EJB CMP, en daar ben ik wel weer erg gelukkig mee.

Beste manier om alles zelf in te zien is gewoon eens een klein testprojectje doen lijkt me.

[.oisyn]

Waarom een mapping naar een relationele database en niet gewoon een pure object georienteerde database?

[MaxxRide]

Misschien loop ik achter, maar volgens mij zijn er weinig oo db's die direct een object persistent kunnen maken. Lijkt me dat je dan nog steeds iets van SQL gebruikt (dat is wat mij bijstaat iig). Hierbij is dat niet nodig.

[Verwijderd]

-FoX- schreef op zaterdag 29 mei 2004 @ 19:17:
Nog maar eens een shopje.

Het verbaasd me echter wel dat er zo weinig mensen ervaringen hebben met ORMtools. Of is het dat schijn bedriegt?

Dat is was ik me net ook zat af te vragen. Momenteel zijn we een nieuw J2EE systeem aan het bouwen, dus we hebben nu de kans om een aantal dingen 'meteen goed' te doen. Nu hebben wij veel objecten die in de DB gestored worden. Andere developpers van mijn team willen liever een hele lijst met queries schrijven die vanuit de code wordt opgeroepen voor het opslaan en ophalen van objecten.
Denk bijvoorbeeld aan een User object en een UserLogic object, waarbij de UserLogic methoden heeft als getUserById(int); en updateUser(User); De implementatie van deze methoden roept dan direct een query aan.

Nu vraag ik me af of deze werkwijze meer de 'norm' is, of dat Hibernate (of eventueel andere O/R mapper) meer de norm is voor zulk soort dingen. Ik had zelf de indruk dat Hibernate toch wel meer gebruikt wordt.

Het tegenargument tegen Hibernate is dat de Hibernate mapping files eigenlijk ook weer een query is, zodat het niet uitmaakt of je nou in Hibernate of in SQL de mapping maakt tussen je objecten en je tables in de DB.

Wat denken jullie? Wat is slim?

[momania]

Verwijderd schreef op vrijdag 27 mei 2005 @ 14:41:
[...]

Wat denken jullie? Wat is slim?

Hibernate maakt ook wel queries idd, grootste voordeel daarvan is dat je ze zelf niet hoeft te schrijven.

Zelf DAO's opzetten en alle queries schrijven voor persistency is gewoon enorm veel werk.

Voor Hibernate zijn er goede plugins te vinden voor eclipse bijvoorbeeld, waarbij je alleen even aangeeft waar je database is, hij leest de tabellen eruit en maakt dan de xml mapping files voor je.
Alles wat je dan nog hoeft te doen is de gegenereerde classnamen en attributes te hernoemen naar hoe je ze zelf wilt hebben en je kan de classes laten genereren.

De gene die ik op m'n werk heb gebruikt is Hibernate Synchronizer.
Die maakt ook voor elke class een DAO erbij, zodat je niet meer hoeft te casten etc. Ook zit er een basis DAO bij met convenience methods om sessions te creeeren en transactions te starten, etc.
(wel hebben we de plugin nog wat gecustomized, omdat bijvoorbeeld de getInstance() methods van die DAO's nog niet synchronized waren etc.)

Ik weet iig dat wij met hibernate ontzettend veel werk hebben bespaart, want we hadden binnen een week de hele domein laag klaar staan. Enige dat je tijdens verder verloop van je project nog doet is wat fine-tuning (dingen als sommige collecties sorted maken, of ander type (List/Map/Set), etc)

Ik zou er echt niet meer aan moeten denken om voor zulke dingen zelf nog een lading queries te moeten maken...

[MaxxRide]

Hoe zit het met een upgrade. Stel ik heb een systeem en dat pas ik aan wat extra funcionaliteit members toevoegen/ verwijderen etc. Hoe gaat hibernate dan om met de conversie van de database? Wordt dat allemaal voor je geregeld? Ik zou namelijk niet willen dan een productiedatabase naar zijn grootje gaat!

[Verwijderd]

MaxxRide schreef op vrijdag 27 mei 2005 @ 16:01:
Hoe zit het met een upgrade. Stel ik heb een systeem en dat pas ik aan wat extra funcionaliteit members toevoegen/ verwijderen etc. Hoe gaat hibernate dan om met de conversie van de database? Wordt dat allemaal voor je geregeld? Ik zou namelijk niet willen dan een productiedatabase naar zijn grootje gaat!

Je kunt automatisch de database laten updaten ipv overschrijven. Dus als je members toevoegd aan een class, verander je de mapping bestand van die class en run je een hibernate tool die de database aanpast of een sql bestand genereert met alter table statements. Ik weet niet hoe het zit als je de structuur van je object model drastisch gaat wijzigen.

[smooc]

Ik gebruik zelf Eclipse in combinatie met de JBoss IDE plugin, deze zorgt er voor dat je XDoclet kan gebruiken waardoor je automatisch mappings kan genereren voor Hibernate. Hibernate in combinatie met Treecache van JBoss is direct ook een clustered caching oplossing. Eenvoudiger (niet clustered) is ook mogelijk met ehcache. Briljant gewoon dat samen

Overigens kan je nog steeds dingen hebben als updateCustomer() etc, je brengt dan scheiding in Data Access Objects en Bussiness Objects, wat geen probleem is natuurlijk. Dit werkt overigens ook prettig met het Spring framework.

Ik ben bijvoorbeeld nu bijvoorbeeld bezig een WebService te bouwen met Tomcat/Axis/Hibernate misschien schakel ik dat nog over naar Jboss zodat clutering piece of cake wordt.

En hibernate heeft in principe niets met XML te maken, configuratie & mappings staan in XML, maar die mappings reflecteren alleen hoe je objecten naar tabllen gemapt moeten worden. Wat is er nu fijner om

Order order = new Order();
Transaction tx = hs.beginTransaction();

hs.save(order);
tx.commit()

in orderid = order.getId()

te doen?

en inheritance:

Customer cust = order.getCustomer();

Allemaal transparant in de database . Geen geklooi meer met JDBC of equivalenten. En blijvend OOP

[Alarmnummer]

Verwijderd schreef op vrijdag 27 mei 2005 @ 14:41:
Het tegenargument tegen Hibernate is dat de Hibernate mapping files eigenlijk ook weer een query is, zodat het niet uitmaakt of je nou in Hibernate of in SQL de mapping maakt tussen je objecten en je tables in de DB.

Met Hibernate kun je veel verder gaan om objecten uit de db te halen dan jij ooit met de hand in SQL zou kunnen doen. Unit of work bv om te achterhalen wat er gesaved moet worden.. kan jij nooit met de hand maken zonder je domain objecten aan te passen.

Wat denken jullie? Wat is slim?

Wij gebruiken Hibernate voor al onze projecten en je weet hoe zo`n zeikerd ik ben, maar Hibernate vind ik een te gekke tool. Je hebt controle als je het nodig hebt, maar het werkt als je geen zin hebt om helemaal in allerlei diepe problematiek te roeren. Mensen die nog met de hand or mappen die moeten een goeie reden hebben om dat te doen, anders ben je echt tijd aan het verkwisten.

[edit]
Een voorbeeld van een van onze Dao`s.

code:

public class ProjectCategorieDao extends HibernateDao {

    public ProjectCategorieDao(SessionFactory sessionFactory){
        super(sessionFactory,ProjectCategorie.class);
    }
}

FindAll, Find met filters, save, update, delete etc zit hier al in... Lijkt me dat het niet veel simpeler kan

[ Voor 21% gewijzigd door Alarmnummer op 27-05-2005 17:52 ]

[Verwijderd]

Misschien een domme vraag: ik veronderstel dat je aan Hibernate vertelt hoe je objecten eruit ziet (Hibernate haalt waarschijnlijk via reflection de data er wel uit), wat de relaties zijn tussen je objecten (om zo je relaties in je tabellen te weerspiegelen)? Genereert Hibernate dan ook automatisch je SQL queries? Hoe zit het trouwens met de efficiëntie? Het lijkt mij niet altijd verstandig om een heel object in te lezen, als je maar enkele member variabelen (enkele kolommen van de overeenkomstige tabel) nodig hebt.

[Thyzz]

.oisyn schreef op zaterdag 29 mei 2004 @ 20:42:
Waarom een mapping naar een relationele database en niet gewoon een pure object georienteerde database?

Daar is laatst een hele discussie over geweest...
zie: [rml][ alg] Waarom altijd RDBMS en geen ODBMS?[/rml]
gaat in de TS er niet helemaal over. Maar het komt er wel in aan bod

[ Voor 10% gewijzigd door Thyzz op 27-05-2005 18:29 ]

[Alarmnummer]

Verwijderd schreef op vrijdag 27 mei 2005 @ 18:28:
Misschien een domme vraag: ik veronderstel dat je aan Hibernate vertelt hoe je objecten eruit ziet

Yep.. daarvoor maak je mapping bestanden.

(Hibernate haalt waarschijnlijk via reflection de data er wel uit), wat de relaties zijn tussen je objecten (om zo je relaties in je tabellen te weerspiegelen)? Genereert Hibernate dan ook automatisch je SQL queries?

Hibernate genereerd idd sql queries om de door jou gevraagde objecten op te halen uit de db.

Hoe zit het trouwens met de efficiëntie? Het lijkt mij niet altijd verstandig om een heel object in te lezen, als je maar enkele member variabelen (enkele kolommen van de overeenkomstige tabel) nodig hebt.

Dan moet je idd niet het hele object uit de db trekken. Dit is een opmerking die ik trouwens wel eens vaker heb gehoord en vind het jammer dat ze soms or-mappers daardoor als slecht bestempelen. Als je een object uit de db nodig bent, dan is een or-mapper je vriend. Or-mappers zijn niet geschikt om alle objecten naar de client te trekken en daar allerlei reporting functionaliteit op los te laten. Soms kan een 'object' beter in de db blijven

[Verwijderd]

Ok, bedankt voor de informatie. Ik heb mij nog niet echt bezig gehouden met OR-mappers. Trouwens, als je maar gedeeltelijke informatie nodig hebt, en het blijft binnen de perken, kan je, denk ik, altijd een afzonderlijke object maken, die alleen die informatie bevat, zodat dus ook alleen die informatie wordt opgevraagd.

[NMe]

Crash_neo schreef op vrijdag 27 mei 2005 @ 18:28:
[...]

Daar is laatst een hele discussie over geweest...
zie: [rml][ alg] Waarom altijd RDBMS en geen ODBMS?[/rml]
gaat in de TS er niet helemaal over. Maar het komt er wel in aan bod

Die vraag stelde .oisyn dan ook ver voordat het topic waarnaar je linkt geopend werd.

[flowerp]

Hibernate klinkt echt harstikke positief, en ook van verschillende vrienden die in de IT werkzaam zijn hoor ik er alleen maar goede dingen over. Eigenlijk is het hele O/R mapper concept zo te horen een grote stap vooruit vergeleken met de queries met de hand schrijven.

Wat ik me nog wel afvraag voordat ik er me echt in ga verdiepen hoe het nu zit met de performance.

Wordt het door het gebruik van Hibernate niet veel langzamer allemaal? Als je nu een complex object uit de DB haalt, stel iets van een Order class die een array met Item objecten heeft. Kan Hibernate zoiets met 1 query ophalen, of worden dat 100'en kleine aparte queries?

Kan Hibernate optimizen voor verschillende DBs? (net zoals compilers voor cpus kunnen optimizen). Het is bijvoorbeeld bekend dat de makers van mysql subqueries niet zo belangrijk vinden maar die van postgresql weer wel. Ik kan me voorstellen dat bij gebruik van mysql een aantal aparte querie sneller zijn, terwijl bij postgresql het wellicht sneller is om 1 wat grotere query te bouwen.

[zneek]

flowerp schreef op vrijdag 27 mei 2005 @ 23:21:
Hibernate klinkt echt harstikke positief, en ook van verschillende vrienden die in de IT werkzaam zijn hoor ik er alleen maar goede dingen over. Eigenlijk is het hele O/R mapper concept zo te horen een grote stap vooruit vergeleken met de queries met de hand schrijven.

Wat ik me nog wel afvraag voordat ik er me echt in ga verdiepen hoe het nu zit met de performance.

Wordt het door het gebruik van Hibernate niet veel langzamer allemaal? Als je nu een complex object uit de DB haalt, stel iets van een Order class die een array met Item objecten heeft. Kan Hibernate zoiets met 1 query ophalen, of worden dat 100'en kleine aparte queries?

Kan Hibernate optimizen voor verschillende DBs? (net zoals compilers voor cpus kunnen optimizen). Het is bijvoorbeeld bekend dat de makers van mysql subqueries niet zo belangrijk vinden maar die van postgresql weer wel. Ik kan me voorstellen dat bij gebruik van mysql een aantal aparte querie sneller zijn, terwijl bij postgresql het wellicht sneller is om 1 wat grotere query te bouwen.

Meten is weten zou ik zeggen. Zet de sql output van Hibernate aan, hang het aan een SQL Server en laat de SQL Server profiler meedraaien.

Ik moet eerlijk zeggen dat ik nog nooit performance problemen met Hibernate heb gehad. Met bijv. EJB CMP wel.

Daarnaast heeft Hibernate ook nog allerlei caching functies, waar ik zelf jammer genoeg nog niet aan toegekomen ben.

[Antediluvian]

Ik heb nu ook al enige ervaring met hibernate en ik zou gewoon niet meer zonder kunnen. Vooral de snelheid van ontwikkelen is bij mij enorm verbeterd danzij hibernate en z'n tools. Ik begin meestal met het schrijven van de mapping files. Dan gewoon het database schema en de classen genereren. Dit staat zelfs in mijn standaard build process. Waar ik vol ongeduld op wacht is de hibernate tool dat java classes genereerd (hbm2java) dat gebruik maakt van generics.

Er word zelfs gewerkt aan een versie die gebruikt maakt van annotations zodat je dus geen aparte mapping files meer moet schrijven.

flowerp schreef op vrijdag 27 mei 2005 @ 23:21:
Wat ik me nog wel afvraag voordat ik er me echt in ga verdiepen hoe het nu zit met de performance.

Wordt het door het gebruik van Hibernate niet veel langzamer allemaal? Als je nu een complex object uit de DB haalt, stel iets van een Order class die een array met Item objecten heeft. Kan Hibernate zoiets met 1 query ophalen, of worden dat 100'en kleine aparte queries?

Je kan hibernate (door de mapping files) optimaliseren zodat hij specifieke (inner-outer) joins gebruikt. Al bij al maakt het volgens mij bij moderne RDBMS niet zo veel uit. Kleine statements kunnen veel rapper uitgevoerd worden en makkelijke gecached worden.

flowerp schreef op vrijdag 27 mei 2005 @ 23:21:
Kan Hibernate optimizen voor verschillende DBs? (net zoals compilers voor cpus kunnen optimizen). Het is bijvoorbeeld bekend dat de makers van mysql subqueries niet zo belangrijk vinden maar die van postgresql weer wel. Ik kan me voorstellen dat bij gebruik van mysql een aantal aparte querie sneller zijn, terwijl bij postgresql het wellicht sneller is om 1 wat grotere query te bouwen.

Je kan in de configuratie file van hibernate (properties en/of xml) instellen welk database dialect je wil gebruiken wat hibernate dus toelaat om geoptimalizeerde queries uit te voeren.

[Verwijderd]

Verwijderd schreef op vrijdag 27 mei 2005 @ 18:28:
Misschien een domme vraag: ik veronderstel dat je aan Hibernate vertelt hoe je objecten eruit ziet (Hibernate haalt waarschijnlijk via reflection de data er wel uit), wat de relaties zijn tussen je objecten (om zo je relaties in je tabellen te weerspiegelen)? Genereert Hibernate dan ook automatisch je SQL queries? Hoe zit het trouwens met de efficiëntie? Het lijkt mij niet altijd verstandig om een heel object in te lezen, als je maar enkele member variabelen (enkele kolommen van de overeenkomstige tabel) nodig hebt.

Dat heet lazy-loading, sinds hibernate3 worden alle objecten bij default lazy-geload, oftwel je relaties worden niet meegenomen tenzij je dat expliciet aangeeft. Dat kun je doen in je mapping configuratie danwel in "Hibernate SQL" doormiddel van het 'fetch' keyword. Verder is het efficienter dan rechtstreeks met een DB babbelen aangeien je nu met proxy objecten te maken hebt (je babbelt niet met je concrete implementatie)

[Verwijderd]

Antediluvian schreef op zaterdag 28 mei 2005 @ 00:20:
Er word zelfs gewerkt aan een versie die gebruikt maakt van annotations zodat je dus geen aparte mapping files meer moet schrijven.

Tevens bestaat er zoiets als XDoclet waardoor de door jou genoemde functionaliteit al een tijdje bestaat...

[The-MeLLeR]

JOw mede-tweakers!

Ik heb inmiddels ervaring met zowel Hibernate (2.1.3) en een ODBMS (DB4O--> www.db4o.com ). Ze hebben allebei wel hun voordelen.

DB4O is merkbaar sneller. Dit komt door de tijd die in het Mappen gaat zitten bij Hibernate. Wel jammer dat DB4O alleen een db-engine is en er dus geen server applicatie bij zit (gevolg: zelf eentje schrijven in 1 uurtje ).

Hibernate let op uniciteitsregels in de DB. Dit mis ik nog bij DB4O.

[zneek]

The-MeLLeR schreef op zondag 29 mei 2005 @ 09:15:
JOw mede-tweakers!

Ik heb inmiddels ervaring met zowel Hibernate (2.1.3) en een ODBMS (DB4O--> www.db4o.com ). Ze hebben allebei wel hun voordelen.

DB4O is merkbaar sneller. Dit komt door de tijd die in het Mappen gaat zitten bij Hibernate. Wel jammer dat DB4O alleen een db-engine is en er dus geen server applicatie bij zit (gevolg: zelf eentje schrijven in 1 uurtje ).

Hibernate let op uniciteitsregels in de DB. Dit mis ik nog bij DB4O.

Daar loopt al een aparte discussie over: [rml][ alg] Waarom altijd RDBMS en geen ODBMS?[/rml]

[momania]

Ik heb al wel gemerkt dat er een bepaalde bug nog steeds in zit:

Op het werk gebruiken we nog een Websphere 3.5.7 omgeving (don't ask ) en dus ook een oudere jvm (1.2.2 geloof ik).

Anyway, het gaat om het volgende:
Omdat we een oudere jvm gebruiken, moet je een Comparator opgeven bij een collection mapping, om een sorted collection te krijgen.
Bij het loaden van deze collection gaat dat prima, maar bij het opslaan gaat dat dus fout.
Ik ben wel ergens 1 vage mailing tegen gekomen, waarbij dit gemeld werd voor hibernate versie (een 1.x versie zelfs geloof ik) en dat het in volgende versies opgelost zou zijn, maar dat is dus niet het geval.

Bij het opslaan ziet hibernate wel dat je de collection gesorteerd wilt hebben, maar negeert de opgegeven Comparator class.
Wat hij wel doet is er van uit gaan dat de inhoud van de collectie allemaal objecten zijn die Comparable implementeren en dus krijg je dat er een ClassCastException wordt gegooid.

Versie 2.1.7 heeft dus nog steeds dit probleem. Ik zal van de week eens controleren of 2.1.8 dit probleem ook nog heeft en kijken of het in 3.0.5 echt opgelost is.
Nu krijg je het dus alleen maar met een oudere jvm, omdat je met jvm's vanaf 1.4 je collection niet meer sorted hoeft te maken met een eigen Comparator, maar het is toch wel even een handige tip lijkt mij

[Verwijderd]

Ik ben zelf net met Hibernate begonnen, en het ziet er wel erg mooi uit.
Wat ik alleen nog niet helemaal snap is wat het voordeel is tegenover een gegenereerde eigen DAL.

Ik heb een tooltje gemaakt wat voor van een tabel in de db een bean klasse maakt en een DAL.

Vervolgens kan ik in mijn code het volgende doen:

code:

Klant klant = new Klant();
klant.setNaam("testje");
KlantDB.add(klant);

Mijn DAL verzorgt verder connection pooling etc, daar hoef ik me dus verder niet druk over te maken. Op deze manier schijf ik zelf dus ook nooit sql, aangezien dat gegenereerd wordt.
Wat is het voordeel van Hibernate tegenover zo'n oplossing?

[Gert]

Hibernate doet wel iets meer dan alleen 1 object opslaan.

Zitten er ook relaties in je dal? Of collecties, een goede cache manager, een uitgebreide query language. Hibernate kan ook xml bestanden gebruiken i.p.v. een rdbms, je kan ze ook mixen.
Automatische contrlole wat er moet worden ge-update om de load te minimaliseren.

Het is natuurlijk vast niet allemaal even nuttig maar waarom zou je het wiel nogmaals uitvinden?

[zneek]

Verwijderd schreef op maandag 30 mei 2005 @ 11:37:
Ik ben zelf net met Hibernate begonnen, en het ziet er wel erg mooi uit.
Wat ik alleen nog niet helemaal snap is wat het voordeel is tegenover een gegenereerde eigen DAL.

Ik heb een tooltje gemaakt wat voor van een tabel in de db een bean klasse maakt en een DAL.

Vervolgens kan ik in mijn code het volgende doen:

code:

Klant klant = new Klant();
klant.setNaam("testje");
KlantDB.add(klant);

Mijn DAL verzorgt verder connection pooling etc, daar hoef ik me dus verder niet druk over te maken. Op deze manier schijf ik zelf dus ook nooit sql, aangezien dat gegenereerd wordt.
Wat is het voordeel van Hibernate tegenover zo'n oplossing?

Maak een klant aan, maak een order aan, maak orderregels aan.

Ik hoef vervolgens alleen maar KlantDao.saveOrUpdate(klant) te doen, en alles staat in de db. Zonder dat ik daar 1 regel code voor hoef te schrijven. Simpelweg de goede set definitie in mijn hbm file is voldoende. Omgekeerd werkt het ook, als ik de klant heb, heb ik ook zijn orders met de daarbij behorende orderregels.

Om maar even 1 feature te noemen die nogal complex is om zelf te bouwen. Natuurlijk kun je het zelf ook allemaal bouwen, maar tegen de tijd dat jij al die functionaliteit erin hebt, ben ik al 25 projecten verder op basis va Hibernate.

[Verwijderd]

Gert schreef op maandag 30 mei 2005 @ 11:43:
[...]
Het is natuurlijk vast niet allemaal even nuttig maar waarom zou je het wiel nogmaals uitvinden?

En ter aanvulling, het is ook altijd raadzaam om een pseudo-standaard te gebruiken, zodat andere (toekomstige) ontwikkelaars makkelijk kunnen inspringen op eerder geschreven code. Wat mij betreft heeft Hibernate die pseudo-standaard status wel verworven.

[Antediluvian]

Hibernate werkt ook met proxies waardoor er optimaal kan gebruik worden gemaakt van lazy loading.

Stel je voor dat je user bv een order opvraagt.

User -> Front (webapp/gui) -> BL -> DAL -> DB

Normaal word de nodige informatie uit de DB gehaalt door de DAL en in een Domain object gegoten.
Dit wordt dan terug gegeven (via Business Logic) aan de Front end.

Nu weet de BL en de DAL niet wat er allemaal met dat domein object gaat gebeuren. Aangezien het om een order gaat zou je alle order detail lijnen reeds kunnen ophalen uit de DB en die reeds in je domein object als een collectie laden.

- Maar wat als er een lijst van orders wordt opgevraagt? Ga je dan ook op voorhand alle orderdetails laden uit de DB. Wellicht heeft de user er slechts 1 order+detials nodig.

- Wat als de user de klant gegevens van dat order wil bekijken?

Een oplossing is natuurlijk dat de frontend aan de BL vraagt als hij bv een lijst van order details nodig heeft. Maar dit resulteerd in een veel omslachtigere BL en DAL.

Want je hebt in je OrderManager niet alleen

code:

public Order getOrder(int orderId);

nodig maar ook

code:

public List<OrderDetail> getOrderDetails(int orderId);

nodig.


Voor dergelijke senarios is Hibernate (met proxies & lazy loading) uitermate geschikt. Je vraag immers je Order domain object op via je BL waarbij enkel de eigen velden worden geladen. Echter kan je aan je domein object zelf vragen getOrderDetails waarbij, mocht deze collectie nog niet geladen zijn, alle order details uit de DB geladen worden op het moment dat je ze nodig hebt (opvraagt).

Het nadeel is dat er geen gebruik wordt gemaakt van joins voor het ophalen van een order samen met zijn detail. (dus geen SELECT * FROM order INNER JOIN orderDetail ON ...) maar aan de andere kant worden er ook geen gegevens opgehaalt die je niet nodig hebt.

Bij dingen die je bij een bepaalde entity wel altijd nodig hebt ( bv Product en ProductLanguageInformation zoals de NL, FR, EN, ... naam) kan je aanduiden dat je geen gebruik wilt maken van lazy loading.

PS:

Ik schreef
Het nadeel is dat er geen gebruik wordt gemaakt van joins voor het ophalen van een order samen met zijn detail.

Dit nadeel is zelfs niet volledig waar. Je kan, als je een bepaalde entiy ophaalt, een aantal parameters meegeven die de manier van ophalen beinvloed waarbij er wel gebruik wordt gemaakt van joins en bv ook lazy loading kan negeren.

[EfBe]

Nadeel van proxies is dat ze toch connected zijn. Wil je disconnected objects gebruiken (en in distributed applicaties moet je wel) dan is het veelal niet zo handig dat je via een proxy bij de db kunt.

Een andere reden is security. Veel grotere ontwikkelteams hebben gewoon eisen dat de gui-boys geen andere mogelijkheid hebben dan de BL laag te gebruiken voor hun data. M.a.w.: als ze order details nodig hebbe, dan moeten ze dat aan de BL laag melden. Doe je dat nl. niet, dan kun je middels lazy loading en een hierarchical stukje code gewoon objects manipuleren waar je bv geen rechten toe hebt als GUI developer, maar je doet het toch want de deadline komt eraan. (lees: je passeert een BL component en omdat je een object manipuleert diep in de graph krijg je je wijzigingen toch in de db).

Ook is lazy loading lang niet altijd efficienter dan bv pre-fetching van bepaalde (!) gerelateerde entities, bv die 5 customers die je laadt en hun laatste 10 orders. Dat kan in 2 queries.

[Verwijderd]

Waar zetten jullie de hibernate "queries" neer?

Stel je hebt het volgende:

code:

session.createQuery("select acc from Account acc")

Waarmee je alle accounts te pakken hebt. Waar zit je dit neer, gewoon op de plek waar je het nodig hebt?

[Antediluvian]

Ik ben accoord dat security hierbij een probleem is maar je kan toch wel security aspects toepassen op je domain objecten. Zo blijft de domain object class mooi overzichtelijk en kan je toch security zoals Access Control inbouwen in het object, waar het toepassing op heeft, zelf.

Security zoals ACL in het domain object zelf steken (via AOP natuurlijk) is volgens mij de beste manier aangezien je er enkel dan zeker van kunt zijn dat zowel de GUI als de BL er niets mee doet wat het niet mag.

[Antediluvian]

Verwijderd schreef op maandag 30 mei 2005 @ 15:22:
Waar zetten jullie de hibernate "queries" neer?

Stel je hebt het volgende:

code:

session.createQuery("select acc from Account acc")

Waarmee je alle accounts te pakken hebt. Waar zit je dit neer, gewoon op de plek waar je het nodig hebt?

Je kan je queries makkelijk definiëren in je mapping file:

code:

<hibernate-mapping>
    <class name="org.ifglobal.dom.User" table="User">
     ...
    </class>

    <query name="org.ifglobal.GetUserByNickNameAndPassword">
        <![CDATA[ from org.ifglobal.dom.User as User where User.nickName = :nickName and User.password = :password]]>
    </query>
</hibernate-mapping>

Deze gebruik je dan op de volgende manier:

code:

Query q = getSession().getNamedQuery("org.ifglobal.GetUserByNickNameAndPassword");
q.setString("nickName", nickName);
q.setString("password", password);
List l = q.list();

if (l.size()==1){
    return (User)l.get(0);
}
return null;

[Verwijderd]

Verwijderd schreef op maandag 30 mei 2005 @ 15:22:
Waar zetten jullie de hibernate "queries" neer?

Stel je hebt het volgende:

code:

session.createQuery("select acc from Account acc")

Waarmee je alle accounts te pakken hebt. Waar zit je dit neer, gewoon op de plek waar je het nodig hebt?

Ben je tevreden met het vorige antwoord of zoek je naar een antwoord als: "In een ObjectManager"?

[Verwijderd]

Verwijderd schreef op maandag 30 mei 2005 @ 15:57:
[...]

Ben je tevreden met het vorige antwoord of zoek je naar een antwoord als: "In een ObjectManager"?

Ik zoek eigenlijk nergens naar, ik ben meer een beetje aan het uitvissen hoe eea het makkelijkste op te zetten en te gebruiken is.
Bovenstaande voorbeeld wist ik bijvoorbeeld niet, en is wel erg handig

[wasigh]

Ik gebruik NHibernate voor een groot Object Model. En ik ben allang blij dat ik niet voor 40 + objecten een insert, delete en update query hoef te schrijven (en herschrijven als ik een keer een property toevoeg of wijzig)

Ik heb ook gewerkt met eigengeschreven DAL's van collega's en dat was een redelijke hel. Ik ben zeer onder de indruk van de funcionaliteiten van (n)Hibernate. Ik ga ervoor zorgen dat het binnen het bedrijf hier de standaard wordt. Wel is het even uitzoek werk zeker met wat ingewikkelde mappings maar daar heb je goede (e-)boeken voor

[Kwistnix]

In hoeverre is Hibernate te vergelijken met bijvoorbeeld Kodo JDO? Met die laatste heb ik wel enige ervaring en ik was niet onder de indruk van de performance (voorzichtig uitgedrukt).

Wat ik ook een nadeel vind is dat de Database een zooitje wordt. Nu zal het niet vaak voorkomen dat je de gegevens in persistente objecten, die Hibernate/Kodo in een relationele DB zijn opgeslagen, buitenom de applicatie (en dus buitenom Hibernate/Kodo) wilt raadplegen, maar dan is de structuur van de database zeer moeilijk te doorgronden.

[ Voor 5% gewijzigd door Kwistnix op 30-05-2005 16:34 ]

[Verwijderd]

FallenAngel666 schreef op maandag 30 mei 2005 @ 16:33:
In hoeverre is Hibernate te vergelijken met bijvoorbeeld Kodo JDO? Met die laatste heb ik wel enige ervaring en ik was niet onder de indruk van de performance (voorzichtig uitgedrukt).

Wat ik ook een nadeel vind is dat de Database een zooitje wordt. Nu zal het niet vaak voorkomen dat je de gegevens in persistente objecten, die Hibernate/Kodo in een relationele DB zijn opgeslagen, buitenom de applicatie (en dus buitenom Hibernate/Kodo) wilt raadplegen, maar dan is de structuur van de database zeer moeilijk te doorgronden.

Je hebt zeker nog nooit een met hibernate gemap-de bean gezien heh. Gewoon normale leesbare velden hoor

[Kwistnix]

Verwijderd schreef op maandag 30 mei 2005 @ 16:37:
[...]

Je hebt zeker nog nooit een met hibernate gemap-de bean gezien heh. Gewoon normale leesbare velden hoor

Nee, dat klopt inderdaad, daarom vroeg ik in hoeverre Hibernate met Kodo JDO te vergelijken is, want ik vind dat die er dus wel een zooitje van maakt. Als je uit zo'n DB buitenom de applicatie en Kodo gegevens wilt halen is dat wel even lastig. Maar dat is mijn mening natuurlijk.

[ Voor 9% gewijzigd door Kwistnix op 30-05-2005 16:41 ]

[Antediluvian]

Verwijderd schreef op maandag 30 mei 2005 @ 16:16:
Bovenstaande voorbeeld wist ik bijvoorbeeld niet, en is wel erg handig

Er zijn zeer veel manieren om een entity uit de database te laden.
Zo kan je makkelijk Person aPerson = (Person) session.load(Person.class, personId); maar nog veel meer. Zie de online reference voor meer tekst en uitleg.

Als je trouwens op zoek bent naar een boek(je) om hibernate te leren dan raad ik "Hibernate, a developers notebook" aan. Het is een klein boekje die je op een duidelijke, doe gerichte manier uitlegt hoe hibernate in elkaar steekt en hoe je het kan gebruiken. Voor de meer expert zaken kan je daarna terecht bij de online reference documentatie.

[ Voor 11% gewijzigd door Antediluvian op 30-05-2005 16:54 ]

[Antediluvian]

FallenAngel666 schreef op maandag 30 mei 2005 @ 16:40:
Nee, dat klopt inderdaad, daarom vroeg ik in hoeverre Hibernate met Kodo JDO te vergelijken is, want ik vind dat die er dus wel een zooitje van maakt. Als je uit zo'n DB buitenom de applicatie en Kodo gegevens wilt halen is dat wel even lastig. Maar dat is mijn mening natuurlijk.

Je maakt toch de database volledig zoals jij wil (bij hibernate toch). Er bestaan zelfs tools die de hibernate mapping files kunnen genereren vanuit een bestaand database schema. Je moet dus bij het ontwerpen van je DB totaal geen rekening houden of je nu met hibernate of met bv JDBC werkt.

[Verwijderd]

Antediluvian schreef op maandag 30 mei 2005 @ 18:40:
[...]


Je maakt toch de database volledig zoals jij wil (bij hibernate toch). Er bestaan zelfs tools die de hibernate mapping files kunnen genereren vanuit een bestaand database schema. Je moet dus bij het ontwerpen van je DB totaal geen rekening houden of je nu met hibernate of met bv JDBC werkt.

Welke tool werkt goed hiervoor? Ik heb inmiddels "Hibernate Synchronizer" geprobeerd, die is wel mooi maar ondersteund geen Hibernate 3, en de eclipse plugin uit het Hibernate tools pakketje.
De laatste vond ik niet niet lekker werken, en wil op de een of andere manier __ voor elke tabelnaam hebben.

[Verwijderd]

zelf mappings schrijven levert mij toch altijd het meest gewenste resultaat

[Antediluvian]

Ik begin ook liever met het schrijven van mapping files en gebruik dan de hbm2ddl tool voor het genereren van het DB schema en hbm2java tool voor het genereren van de java domain objects.

Als je wil beginnen met het db schema er vandaar uit de hibernate mappings (hbm) wil genereren kan je gebruik maken van Middlegen of de ddl2hbm tool. Hiermee heb ik echt niet zo veel ervaring maar er is heel wat informatie over te vinden, bv hier.


Een voordeel van hiberante is ook dat je het zo kan instellen dat het met verschillende datasource tegelijk kan werken. Zo kan je bv een volwaardige database gebruiken met daarnaast een xml representatie van je data die tegelijk wordt geupdate.

Ik ben momenteel aan het kijken hoe ik de index files van Lucene automatish kan laten bijwerken op het moment dat hibernate iets (update/insert) doet met de database. Zijn er mensen die dit reeds gedaan hebben? Wat zijn jullie ervaringen hiermee?

[ Voor 36% gewijzigd door Antediluvian op 30-05-2005 19:30 ]

[Kwistnix]

Antediluvian schreef op maandag 30 mei 2005 @ 18:40:
[...]


Je maakt toch de database volledig zoals jij wil (bij hibernate toch). Er bestaan zelfs tools die de hibernate mapping files kunnen genereren vanuit een bestaand database schema. Je moet dus bij het ontwerpen van je DB totaal geen rekening houden of je nu met hibernate of met bv JDBC werkt.

Bij Kodo moet jij dus helemaal niets ontwerpen. Je geeft aan welke klassen er persistent moeten maken en in welke database dat moet gebeuren en Kodo maakt automagisch allehande tabellen en velden aan met de meest funky namen.

[momania]

Verwijderd schreef op maandag 30 mei 2005 @ 18:44:
[...]


Welke tool werkt goed hiervoor? Ik heb inmiddels "Hibernate Synchronizer" geprobeerd, die is wel mooi maar ondersteund geen Hibernate 3

Hoezo werkt deze niet met Hibernate 3 ?
Je weet dat je zelf die snippets aan kan passen waaruit je java files worden gegenereerd?

Ook in de jar van Hibernate Synchronizer zitten nog wat snippets, die je niet via de plugin kan editten, maar natuurlijk wel direct in je jar

[Alarmnummer]

Antediluvian schreef op maandag 30 mei 2005 @ 16:52:
[...]
Als je trouwens op zoek bent naar een boek(je) om hibernate te leren dan raad ik "Hibernate, a developers notebook" aan.

Dat boek vond ik nogal matig, vooral als je hem tegenover Hibernate in Action zet.

[Alarmnummer]

Antediluvian schreef op maandag 30 mei 2005 @ 19:20:
Ik ben momenteel aan het kijken hoe ik de index files van Lucene automatish kan laten bijwerken op het moment dat hibernate iets (update/insert) doet met de database. Zijn er mensen die dit reeds gedaan hebben? Wat zijn jullie ervaringen hiermee?

Ik heb dat op dit moment opgelost door in de db een update kolom mee te nemen in het record en Lucene een keer in de zoveel tijd laten controleren welke kolommen zijn bijgewerkt. Voordeel aan deze aanpak is dat je niet per ongeluk een record kunt vergeten als je buiten om hibernate iets aanpast. Nadeel is dat het db model aangepast moet worden, maar dat was in dit geval geen probleem. (De db is toch alleen voor opslag van metadata mbt te indexeren documenten)

[matthijsln]

Sinds een paar weken ben ik met een project begonnen waarin ik voor het eerst ook Hibernate (versie 3) gebruik. Om van het bestaande schema Hibernate mappings te genereren en daarvan weer de POJO objecten te genereren heb ik gebruik gemaakt van Middlegen en hbm2java (de versies voor Hibernate 2), maar echt onder de indruk van die tools ben ik niet.

In Middlegen zit wel een GUI maar alle Hibernate properties zijn voorzover ik heb geprobeerd niet aan te passen en dus moet je alle mappings nog handmatig doorlopen (zoals als tabel/veldnamen quoten [uiteraard heb ik zelf niet de namen met spaties/leestekens erin bedacht...], namen aanpassen, relaties goedzetten...) en hbm2java loopt nog wel eens vast omdat deze voor elke mapping file de mapping DTD downloadt?

Maar goed daar is allemaal wel overheen te komen. Voor de rest ben ik wel te spreken over Hibernate, vooral in combinatie met JSTL/EL in een JSP pagina is het heel eenvoudig om objecten weer te geven.

Alhoewel ik nog niet echt veel gebruik gemaakt heb van geavanceerde features van Hibernate. Misschien dat ik later in het project dus nog meer tegenkom.

[Antediluvian]

Alarmnummer schreef op maandag 30 mei 2005 @ 20:41:
[...]
Dat boek vond ik nogal matig, vooral als je hem tegenover Hibernate in Action zet.

Het is dan ook maar een beginners boekje. Ik vond het makkelijk om te lezen en duidelijk om mee te starten en voor meer gedetailleerde info gebruik ik de online reference documentatie. Ik geloof best dat Hibernate in Action een veel beter boek is maar aangezien de online documentatie van hibernate best wel goed is heb ik nog geen nood gehad aan een uitgebreid boek.

Alarmnummer schreef op maandag 30 mei 2005 @ 20:44:
[...]

Ik heb dat op dit moment opgelost door in de db een update kolom mee te nemen in het record en Lucene een keer in de zoveel tijd laten controleren welke kolommen zijn bijgewerkt. Voordeel aan deze aanpak is dat je niet per ongeluk een record kunt vergeten als je buiten om hibernate iets aanpast. Nadeel is dat het db model aangepast moet worden, maar dat was in dit geval geen probleem. (De db is toch alleen voor opslag van metadata mbt te indexeren documenten)

Maak je hier gebruik van Spring Job Scheduling om dit om de te realiseren?
Heb je dan niet het nadeel dat een resultaat dat je toevoegt (bv een nieuw product) niet direct terug te vinden is met een Lucene search?
Volgens mij is een combinatie van de 2 de beste oplossing. Dus via hibernate de index files altijd laten aanpassen en om de zoveel tijd een extra controle laten uitvoeren voor gegeven die niet via hibernate in de DB zijn terecht gekomen.

[Antediluvian]

matthijsln schreef op maandag 30 mei 2005 @ 23:17:
hbm2java loopt nog wel eens vast omdat deze voor elke mapping file de mapping DTD downloadt?

Ik heb dit probleem nog nooit gehad. Ik maak trouwens gebruik van maven en de hibernate plugin.

Wel moet ik eerlijk toegeven dat ik deze tools enkel gebruik in combinatie met hibernate 2. Bij het project waar ik hibernate 3 gebruik, gebruik ik ook generics. Aangezien er nog geen hbm2java tool is voor hibernate 3 en generics moet ik alle veranderingen die ik een hbm file doe ook manueel aanpassen in het domain object.

[ Voor 4% gewijzigd door Antediluvian op 30-05-2005 23:40 ]

[Alarmnummer]

Maak je hier gebruik van Spring Job Scheduling om dit om de te realiseren?

Ik maak gebruik van Quartz icm Spring, maar ik heb op dit moment niet in een 'whoehoe' gevoel bij deze combinatie. Als je diep in Quartz wilt komen, loop je snel spaak. Ik zit er aan te denken om Quartz voor een aantal schedulers eruit te kicken en te vervangen door de concurrency library van doug lea. Enigste wat ik nog nodig ben is manier om eenvoudig timer-expressies te schrijven.

Heb je dan niet het nadeel dat een resultaat dat je toevoegt (bv een nieuw product) niet direct terug te vinden is met een Lucene search?

Tja... dat is sowieso onmogelijk om direct terug te vinden aangezien het wegschrijven naar de index ook tijd kost. En verder kan je de timer bv op een relatief korte periode zetten (bv een kwartier).

Volgens mij is een combinatie van de 2 de beste oplossing. Dus via hibernate de index files altijd laten aanpassen en om de zoveel tijd een extra controle laten uitvoeren voor gegeven die niet via hibernate in de DB zijn terecht gekomen.

Dat zou een oplossing kunnen zijn, maar je hebt wel een stuk meer werk. De vraag is of het noodzakelijk is.

[Antediluvian]

Alarmnummer schreef op maandag 30 mei 2005 @ 23:40:
Tja... dat is sowieso onmogelijk om direct terug te vinden aangezien het wegschrijven naar de index ook tijd kost. En verder kan je de timer bv op een relatief korte periode zetten (bv een kwartier).

Als je die timer op zo'n korte priode zet kost dit dan niet te veel processing power. Bij een kleine hoeveelheid record zal het zeker geen probleem zijn, maar wat als je met veel record zit?

Dat zou een oplossing kunnen zijn, maar je hebt wel een stuk meer werk. De vraag is of het noodzakelijk is.

Ik heb nog 2 projecten lopen waar ik (tegen end volgende week) Lucene wil in introduceren. Ik zal beide manieren proberen (timed update & timed + realtime update) en zal dan mijn ervaringen hiermee posten.

[Alarmnummer]

Antediluvian schreef op maandag 30 mei 2005 @ 23:48:
Als je die timer op zo'n korte priode zet kost dit dan niet te veel processing power. Bij een kleine hoeveelheid record zal het zeker geen probleem zijn, maar wat als je met veel record zit?

Ligt aan de hoeveelheid records denk ik. Maar ik heb eerlijkgezegd geen enkel benul van de load van een query voor bv 1 miljoen records.. dus select bla from documents where lastchange > ...

Ik zou echt niet weten wat de performance inpakt daarvan is. Bij ons maakt het niet veel uit omdat de metadata database nooit door veel gebruikers zal worden aangesproken (alleen mensen die rechten hebben om metadata wijzigingen door te voeren). Dus ook al heeft die db het zwaar.. who cares.

Voor andere systemen zou ik het niet weten.. Mijn vraag is: is het erg dat het een uur duurt voordat het erin zit?

Ik heb nog 2 projecten lopen waar ik (tegen end volgende week) Lucene wil in introduceren. Ik zal beide manieren proberen (timed update & timed + realtime update) en zal dan mijn ervaringen hiermee posten.

Pas maar goed op met allerlei concurrency problematiek van Lucene Realtime garantie kan je bij Lucene niet geven.

[Verwijderd]

Wat ik nog steeds niet goed kan vinden:

Kan hibernate nou bij het ophalen van een wat complexer object dit altijd met 1 query doen? Of gaat ie er toch allemaal kleinere queries van maken?

Is er een mogelijkheid om expliciet af te dwingen dat iets perse in 1 (grote) query moet?

[Verwijderd]

Waarom kijk je niet eens achter de schermen mee met show_sql = true

[Verwijderd]

Verwijderd schreef op dinsdag 31 mei 2005 @ 11:36:
Wat ik nog steeds niet goed kan vinden:

Kan hibernate nou bij het ophalen van een wat complexer object dit altijd met 1 query doen? Of gaat ie er toch allemaal kleinere queries van maken?

Is er een mogelijkheid om expliciet af te dwingen dat iets perse in 1 (grote) query moet?

Volgens mij kun je dat voor een deel afdwingen met fetching strategies.
Hier kun je daar het eea over vinden: http://www.hibernate.org/...html#performance-fetching

[Verwijderd]

[quote]Antediluvian schreef op maandag 30 mei 2005 @ 23:30:
[...]

Het is dan ook maar een beginners boekje. Ik vond het makkelijk om te lezen en duidelijk om mee te starten en voor meer gedetailleerde info gebruik ik de online reference documentatie. Ik geloof best dat Hibernate in Action een veel beter boek is maar aangezien de online documentatie van hibernate best wel goed is heb ik nog geen nood gehad aan een uitgebreid boek.

/quote]

Ik heb het boekje besteld, en ben er ook wel blij mee. Het gaat inderdaad niet erg diep op alles in, maar op deze manier kun je wel snel aan de slag

Overigens maak ik nu ook eerst mijn mapping files, en laat ik mijn db en java genereren dmv een anttask. Werkt ideaal zo.

[-FoX-]

Ikzelf vind Hibernate in Action wel een goed boek, maar het boek bevat zoveel informatie dat je hem best wel meerdere keren doorneemt... of bepaalde stukken zeker achteraf eens herleest.

Voor de rest ben ik erg te spreken over Hibernate; het heeft me al heel veel tijd bespaart. Toch merk ik dat de grote bedrijven, vooral de financiele sector, niet erg happig zijn op dergelijke opensource projecten. Zij houden het liever bij de logge EJB technologie omdat ze dan ondersteuning krijgen van de grote vendors (zoals IBM)

[ahriman]

Alarmnummer schreef op maandag 30 mei 2005 @ 20:41:
[...]

Dat boek vond ik nogal matig, vooral als je hem tegenover Hibernate in Action zet.

Inderdaad, wij hebben op de zaak ook eerst die Developer's Notebook aangeschaft, maar die viel erg tegen. De basis wordt wel behandeld, maar als je specifieke zaken zoekt, of wat dieper de theorie in wil, moet je echt Hibernate in Action hebben.

We gebruiken Hibernate nu al een tijdje, moet zeggen dat het goed bevalt.

...op een aantal eigenaardigheden na die nogal wat tijd gekost hebben, bijvoorbeeld
bij het aanmaken van nieuwe objecten, waarvan het id in de table een autoincrement is.
Dan moet je net weten welke generator-class je moet hebben (native) en dat je

code:

hibernate.jdbc.use_get_generated_keys false

moet configureren.

Dit soort dingen zijn gewoon matig gedocumenteerd.

[Alarmnummer]

Wat dacht je dan van relaties en allerlei cascade problematiek In grote lijnen staat er wel wat maar net niet genoeg om zekerheid te krijgen hoe het nu echt in elkaar zit. Ik moet eerlijk toegeven dat het cascase gedeelte van Hibernate op dit moment nog totale hocus pocus voor me is.

[zneek]

Alarmnummer schreef op vrijdag 03 juni 2005 @ 17:03:
Wat dacht je dan van relaties en allerlei cascade problematiek In grote lijnen staat er wel wat maar net niet genoeg om zekerheid te krijgen hoe het nu echt in elkaar zit. Ik moet eerlijk toegeven dat het cascase gedeelte van Hibernate op dit moment nog totale hocus pocus voor me is.

Anders voor mij wel. Ik ben al 2 dagen bezig mijn webapplicatie correct te laten cascaden. Ik krijg het niet voor elkaar. Constant loop ik weer tegen een tegenstrijdigheid aan: ok, met de huidige hbm en java code wordt de gerelateerde entitity correct ge-cascade-delete, maar oeps, hij sleept alle indirect gerelateerde entities ook mee de prullenbak in.

Ik kan geen goede documentatie vinden. Niet op de Hibernate site, niet in "Hibernate in action". Telkens leggen ze dingen uit aan de hand van voorbeelden die of niet realistisch zijn, of te klein/simpel zijn of veel te complex zijn. Ik weet hoe ik een one-to-many en een many-to-one moet modelleren. Maar hoe ga ik te werk als mijn model niet ophoudt bij die 2 zaken? Dat vind ik dus niet terug in de documentatie. Met als gevolg dat ik trial-on-error verder moet, en dat kost allemachtig veel tijd.

Stel nou dat je 2 zelfstandige entities hebt, klant en eigenschap. Vervolgens wil je die 2 aan elkaar gaan koppelen. Met een many-to-many krijg ik dat voor elkaar. Nette cascades naar de koppeltabel. Maar stop er een koppel-entity tussen. Hoe cascade ik dan van klant naar klanteigenschap, zonder de eigenschap ook te deleten? En omgekeerd. Ik loop constant tegen Null FKs, cascade saves en weet ik allemaal wat aan. Het zal wel materieblindheid zijn veroorzaakt door 2 dagen non-stop klooien met Hibernate. Als iemand nog wat goede voorbeelden heeft hou ik me aanbevolen

[Tubby]

dan zet je de cascade van de klant naar de koppeleigenschap op all en de cascade van de eigenschap naar de koppeleigenschap op save-update of zelfs none. Cascade's zijn in beide richtingen onafhankelijk te configureren. In jouw geval heb je dus voldoende combinaties om uit te proberen

Heeft iemand al een degelijke one-to-one relationship voor elkaar gekregen, want op de site van hibernate adviseren ze de one-to-one mapping niet te gebruiken en vanuit beide kanten een one-to-many te declareren met dezelfde foreign-key name. Maar ik blijf me mateloos irriteren aan de duplicate foreign key foutmelding die je dan krijgt in je build

[Alarmnummer]

Tubby schreef op vrijdag 03 juni 2005 @ 21:03:
dan zet je de cascade van de klant naar de koppeleigenschap op all en de cascade van de eigenschap naar de koppeleigenschap op save-update of zelfs none. Cascade's zijn in beide richtingen onafhankelijk te configureren. In jouw geval heb je dus voldoende combinaties om uit te proberen

Klinkt niet echt handig

[zneek]

Tubby schreef op vrijdag 03 juni 2005 @ 21:03:
dan zet je de cascade van de klant naar de koppeleigenschap op all en de cascade van de eigenschap naar de koppeleigenschap op save-update of zelfs none. Cascade's zijn in beide richtingen onafhankelijk te configureren. In jouw geval heb je dus voldoende combinaties om uit te proberen

Heeft iemand al een degelijke one-to-one relationship voor elkaar gekregen, want op de site van hibernate adviseren ze de one-to-one mapping niet te gebruiken en vanuit beide kanten een one-to-many te declareren met dezelfde foreign-key name. Maar ik blijf me mateloos irriteren aan de duplicate foreign key foutmelding die je dan krijgt in je build

Ok, en dan verwijder ik een eigenschap. Welke foutmeldingen krijg ik dan allemaal? Let op, ik vraag niet of ik foutmeldingen krijg, want dat weet ik al zeker. Welke krijg ik? Het lijkt simpel, maar het is het niet.

[Tubby]

zneek schreef op vrijdag 03 juni 2005 @ 23:22:
[...]


Ok, en dan verwijder ik een eigenschap. Welke foutmeldingen krijg ik dan allemaal? Let op, ik vraag niet of ik foutmeldingen krijg, want dat weet ik al zeker. Welke krijg ik? Het lijkt simpel, maar het is het niet.

Zou ik maandag uit moeten testen, het kan zijn dat xdoclet automatisch beide zijden van de relatie hetzelfde zet. Om eerlijk te zijn ben ik dat probleem ook niet tegen gekomen, vooral omdat we geen harde delete's doen in de database, vandaar dat alle cascade's op save-update of none staan. Maar uit de documentatie had ik begrepen dat beide zijden onafhankelijk te configureren zijn.

Verder hebben we vooral problemen gehad met het dynamisch aanmaken van velden en tussentijds committen van wijzigen die niet gecommit hadden moeten worden (was gelukkig gewoon een setting )

[Suepahfly]

Ik heb vanuit mijn stageopdracht gekozen voor Hibernate (volgens de docs kan het alles wat ik nodig heb).

Alleen moet ik zeggen dat ik de tut's / docs' iets te beperkt vind. Ik doe een MBO opleiding waar bij programmeren een hele kliene rol speelt (wij doen OO met VB 5. OO pricipes worden niet eens uitgelegt, ik mocht notabene niet eens eens uitleggen hoe je zelf een class maakt aan een medeleerling)

Ik denk dat ik een werkende installatie heb, maar ben er niet zeker van aangezien ik niet zelf een Java app kan schrijven. Dat is eigenlijk het enige wat ik mis in de tut.

[EfBe]

Suepahfly schreef op zaterdag 04 juni 2005 @ 03:56:
(wij doen OO met VB 5. OO pricipes worden niet eens uitgelegt, ik mocht notabene niet eens eens uitleggen hoe je zelf een class maakt aan een medeleerling)

Nee nogal wiedes dat OO principes niet worden uitgelegd, dat is ook nogal moeilijk met VB5, dat geen OO ondersteunt! (alleen COM, maar dat is geen OO). Sommige leraren houden het 'those who can, do;those who can't, teach' wel in ere zeg...

[Antediluvian]

Alarmnummer schreef op maandag 30 mei 2005 @ 20:44:
Ik heb dat op dit moment opgelost door in de db een update kolom mee te nemen in het record en Lucene een keer in de zoveel tijd laten controleren welke kolommen zijn bijgewerkt. Voordeel aan deze aanpak is dat je niet per ongeluk een record kunt vergeten als je buiten om hibernate iets aanpast. Nadeel is dat het db model aangepast moet worden, maar dat was in dit geval geen probleem. (De db is toch alleen voor opslag van metadata mbt te indexeren documenten)

Ik ben momenteel met Lucene aan het spelen en ivm jouw aanpak voeg ik mij het volgende af.
Hoe ga je hier om met verwijderde records?

Als je op bepaalde intervallen je index file bijwerkt dan komen alle nieuwe records wel in je index maar oude records die verwijderd zijn uit je DB blijven in je index staan. Of bouw je je index iedere keer terug van nul op?

[Alarmnummer]

[b][message=23550624,noline]
Ik ben momenteel met Lucene aan het spelen en ivm jouw aanpak voeg ik mij het volgende af.
Hoe ga je hier om met verwijderde records?

Ik heb hiervoor een two-way crawler, die het volgende doet:
van resource naar index (dus resources (kan een file zijn) controleren op updates en dan laten indexeren)
van index naar resource (documenten in de index.. controleren op updates/deletes).

En verder kunnen ook documenten direct geindexeerd worden zonder dat hiervoor de crawler aangesproken hoeft te worden (handig als je update 'direct' wilt doorvoeren).

(Je kunt uiteraard optimaliseren als je de 2 crawls achter elkaar uit voert. Files die je bent tegengekomen op de hd die hoef je niet nog een keer op exist te checken. Voor een file zal dat niet zoveel uitmaken.. maar voor een db call kan dat andere koek zijn)

Als je op bepaalde intervallen je index file bijwerkt dan komen alle nieuwe records wel in je index maar oude records die verwijderd zijn uit je DB blijven in je index staan.

Ik laat ze op dit moment nog in de db staan. Zoveel ruimte neemt het voorlopig nog niet in beslag. Later ga ik eventueel kijken naar een andere oplossing.

Of bouw je je index iedere keer terug van nul op?

Dat is ook een optie. Maar daarvoor moet je het document dus zelf volledig analyzeren en dat kan soms ongewenst zijn (en dat is het dus bij ons... ). We zijn voor een klant bezig die een gigantische lading documenten uiteindelijk in ons zoeksysteem gaat onderbrengen en daarbij is het niet wenselijk dat we de index opnieuw op gaan bouwen omdat er updates zijn.

[ Voor 9% gewijzigd door Alarmnummer op 08-06-2005 16:42 ]