Hibernate und seine Objektreferenzen

[carom]

Hallo!

Gerade bin ich dabei, Hibernate mit einem OODBS (genauer gesagt db4o) zu vergleichen. An zwei stellen bräuchte ich jedoch mal kurz eure Hilfe.

1.) Im folgenden erzähle ich kurz was über db4o und würde im Anschluss gerne wissen, wie Hibernate das genau lösen würde.

db4o erstellt für eine Session einen Cache von Referenzen. Wenn man nun zwei völlig verschiedene Queries absetzt, die aus logischer Sicht jedoch das selbe Objekt zurückliefern, dann kann man sie in Java mit == tatsächlich erfolgreich auf Gleichheit prüfen.

Wenn man solch ein Objekt aus der Datenbank nun modifiziert und wieder abspeichert, dann wird in der Datenbank automatisch das richtige Objekt geupdated - eben wegen der Referenz.

Wenn man die Session jedoch schließt und wieder öffnet, dann sind die Referenzen in den Cache hinein verloren. Speichert man das Objekt von oben erneut, dann wird ein Update gemacht, sondern ein neues Objekt in der Datenbank abgelegt.

Anmerkung: die Objekte, die man abspeichern kann, haben keinen Primärschlüssel wie bei Hibernate und müssen auch nicht serialisierbar sein. POJOs eben.​

Jetzt frage ich mich, wie Hibernate analog dazu verfährt. Es geht ja schon damit los, dass Objekte, welche man mit Hibernate speichern möchte, ein Primärschlüsselattribut bekommen.

Muss Hibernate dann überhaupt mit Referenzen arbeiten, wenn sowieso Primärschlüssel als Identifier zum Einsatz kommen?
Würden 2 logisch gleiche Objekte, die man aber mit 2 unterschiedlichen Queries erhalten hat, in Java trotzdem mit == erfolgreich auf Gleichheit prüfbar sein?

Ich habe in einem Vorlesungsscript im Netz folgendes gefunden:

Retrieving referenced objects
Referenced objects can be accessed as long as the session is open

Also scheinen Referenzen doch eine Rolle zu spielen. Was passiert, wenn man in Hibernate eine Session schließt und wieder öffnet? Das mit dem "accessed" von oben verstehe ich nicht.


2)

In db4o werden ganze Objektgraphen mit in die DB gezogen. Eine selbst geschriebene Klasse für verkettete Listen (mit internen Nodes als eigener Typ) würde einfach dadurch in der DB gespeichert werden, in dem man das Listenobjekt abspeichert - alle Nodes folgen automatisch hinterher.
Wenn man die Liste wieder haben möchte, dann holt man sich das Listenobjekt aus der DB zurück und die Nodes sind dort, wo sie hingehören.

Dass Hibernate nur einzelne Objekte speichern kann und nicht den ganzen Objektgraph einsaugt, das meine ich sicher zu wissen.

Wie würde man jedoch mit Hibernate analog zu oben solch ein Listenobjekt mit all seinen Nodes abspeichern, und vor allem, wie würde man das Objekt mit all seinen Nodes wieder bekommen? Um das zu verstehen muss ich wahrscheinlich erst mal Frage 1 von oben (das mit den Referenzen) verstehen.


Über Antworten würde ich mich sehr freuen, vielen Dank!

 

[gafktor]

Hallo camron,

was hast dur vor? Eine Arbeit über den Vergleich von object-orientierten zu relationen DB zu schreiben????:L
Oder suchst du für dich eine Möglichkeit deine Daten in einer DB dauerhaft zu speichern?

db4o erstellt für eine Session einen Cache von Referenzen. Wenn man nun zwei völlig verschiedene Queries absetzt, die aus logischer Sicht jedoch das selbe Objekt zurückliefern, dann kann man sie in Java mit == tatsächlich erfolgreich auf Gleichheit prüfen.

Wenn man solch ein Objekt aus der Datenbank nun modifiziert und wieder abspeichert, dann wird in der Datenbank automatisch das richtige Objekt geupdated - eben wegen der Referenz.

Wenn man die Session jedoch schließt und wieder öffnet, dann sind die Referenzen in den Cache hinein verloren. Speichert man das Objekt von oben erneut, dann wird ein Update gemacht, sondern ein neues Objekt in der Datenbank abgelegt.

Der Vergleich über "==" zeigt auf die gleiche Referenz, also auf die gleiche Speicherstelle. Willst du auf inhaltliche Gleichheit prüfen, solltest du equals() (natürlich auf die Klassen angepasst) verwenden. Oder anders: über die where-Clausel im Query legst du letzlich fest wieweit die oder zurückgelieferten Objecte dem gesuchtem entsprechen.

Wenn man die Session jedoch schließt und wieder öffnet, dann sind die Referenzen in den Cache hinein verloren. Speichert man das Objekt von oben erneut, dann wird ein Update gemacht, sondern ein neues Objekt in der Datenbank abgelegt.

Ich nehm mal an, das du dir nicht die Mühe gemacht hast vorher über einen Query abzufragen, ob das Ding schon in der DB vorhanden ist.

 

[maki]

Zuerst: Referenzen an sich nutzen einem im allgmeinen nicht viel, jedes neu erzeugte Objekt hat eine eindeutige Referenz, aber wie verhindert man, dass dasselbe Objekt mehrmals instanziiert wird?
Da es ja um Persistenz geht, es muss festgelegt werden, wann Objekte gleich sind, wenn sie noch nicht im Speicher sind.

db4o erstellt für eine Session einen Cache von Referenzen. Wenn man nun zwei völlig verschiedene Queries absetzt, die aus logischer Sicht jedoch das selbe Objekt zurückliefern, dann kann man sie in Java mit == tatsächlich erfolgreich auf Gleichheit prüfen.

Ist auch bei Hibernate/Eclipse/JPA so, solange equals richtig implementiert ist, irgendwie muss ja festgelegt werden was die "Objektidentität" ist.

Wenn man solch ein Objekt aus der Datenbank nun modifiziert und wieder abspeichert, dann wird in der Datenbank automatisch das richtige Objekt geupdated - eben wegen der Referenz.

Wenn man die Session jedoch schließt und wieder öffnet, dann sind die Referenzen in den Cache hinein verloren. Speichert man das Objekt von oben erneut, dann wird ein Update gemacht, sondern ein neues Objekt in der Datenbank abgelegt.

Anmerkung: die Objekte, die man abspeichern kann, haben keinen Primärschlüssel wie bei Hibernate und müssen auch nicht serialisierbar sein. POJOs eben.

Hibernate bietet zB. die Möglichkeit, anhand einer fehlenden ID fetzustellen, dass ein Insert gemacht werden muss wenn man saveOrUpdate() nutzt.
JPA bietet etwas ähnliches, merge(..), k.A. ehrlich gesagt wie da festgestellt wird ob ein INsert oder Update gemacht werden muss.

In db4o werden ganze Objektgraphen mit in die DB gezogen. Eine selbst geschriebene Klasse für verkettete Listen (mit internen Nodes als eigener Typ) würde einfach dadurch in der DB gespeichert werden, in dem man das Listenobjekt abspeichert - alle Nodes folgen automatisch hinterher.
Wenn man die Liste wieder haben möchte, dann holt man sich das Listenobjekt aus der DB zurück und die Nodes sind dort, wo sie hingehören.

So in etwa ist das auch mit Hibernate/EclipseLink bzw. JPA.

Dass Hibernate nur einzelne Objekte speichern kann und nicht den ganzen Objektgraph einsaugt, das meine ich sicher zu wissen.

Nö, Hibernate, EclipseLink (bzw. JPA) und DataNuclues können auch ganze Objektgraphen speichern, kommt halt auf die Cascade an.

Wie gut kennst du dich denn mit RDBMS im allgemeinen aus?
Was du wirklich vergleichst ist nicht Hibernate mit db4o, sondern ORM mit OODBS, da wären gute Kenntnisse in zumindest einem der Felder vorteilhaft wenn man vergleichen will.

 

[carom]

Danke euch beiden

@gafktor:

Habe mich wohl zu umständlich ausgedrückt, das mit den Referenzen ist ja gerade gewollt, um ein Objekt in der DB wieder dort abzulegen, wo es davor auch gelegen hat. und wenn man ein Objekt auf 2 komplett verschiedene Arten aus der DB bekommt und der Vergleich mit == eben true ist, dann weiß man, dass das Objekt dahinter ein und das selbe ist. Manipulierst du die eine Referenz und schiebst sie in die DB zurück und anschließend die andere Referenz, dann wurde in der DB exakt ein Objekt geändert.

Zuerst: Referenzen an sich nutzen einem im allgmeinen nicht viel, jedes neu erzeugte Objekt hat eine eindeutige Referenz, aber wie verhindert man, dass dasselbe Objekt mehrmals instanziiert wird?

Wie instanziiert man ein Objekt mehrmals?
Vielleicht könntest du auf das mit den Referenzen nochmal näher drauf eingehen, stehe da wohl gerade auf dem Schlauch. db4o nutzt ausschließlich die Referenz um zu schauen, was in der Datenbank geupdated und was neu eingefügt werden muss. equals nützt da ja nichts.

Ist auch bei Hibernate/Eclipse/JPA so, solange equals richtig implementiert ist, irgendwie muss ja festgelegt werden was die "Objektidentität" ist.

Hm, mal anders gefragt. Du hast 100 Objekte des gleichen Typs in deiner Datenbank, diese haben auch noch den gleichen Inhalt. Jetzt speicherst du ein weiteres, neues Objekt in deiner Datenbank, welches wieder vom gleichen Typ ist und wieder den gleichen Inhalt hat (also praktisch 101 gleiche Objekte in der DB). Dann holst du alle 101 Objekte aus der DB heraus und vergleichst die Referenz (==, nicht equals) von allen 101 erhaltenen Objekten mit dem Objekt, welches du gerade abgespeichert hast. Ist der Vergleich in Hibernate dann exakt 1 mal true? So wäre es in db4o.

Hibernate bietet zB. die Möglichkeit, anhand einer fehlenden ID fetzustellen, dass ein Insert gemacht werden muss wenn man saveOrUpdate() nutzt.

Okay, das klingt also nach Vergleich der ID, nicht nach Referenzvergleich.

Nö, Hibernate, EclipseLink (bzw. JPA) und DataNuclues können auch ganze Objektgraphen speichern, kommt halt auf die Cascade an.

Weißt du, seit wann Hibernate in seiner Reinform das kann? Dann muss ich hier veraltete Informationen haben.

Wie gut kennst du dich denn mit RDBMS im allgemeinen aus?
Was du wirklich vergleichst ist nicht Hibernate mit db4o, sondern ORM mit OODBS, da wären gute Kenntnisse in zumindest einem der Felder vorteilhaft wenn man vergleichen will.

Mit RDBMS kenne ich mich ausnahmsweise sehr gut aus, aber ich weiß nicht genau, wie mir das hier weiterhilft Mich interessiert vor allem, wie die einzelnen Systeme aus logischer Sicht identische Objekte in- und außerhalb der DB "abgleichen". db4o kennt lediglich "store" und nichts anderes (das ist das, was bei Hibernate saveOrUpdate heißt) und dort geht das eben über die Referenzen. Dass Hibernate keine Objekte, sondern Zeilen in einem RDBMS speichert ist mir schon klar, da kann man schlecht Referenzen vergleichen. Dafür muss wahrscheinlich dann die Id herhalten.

 

[maki]

Wie instanziiert man ein Objekt mehrmals?

Indem man zwei Objekte per Konstrutor oder sonst instatiiert, die eigentlich eines sind, oder man cloned sie, oder oder oder...
Die Objektidentität musst du doch irgendwie festlegen?

Vielleicht könntest du auf das mit den Referenzen nochmal näher drauf eingehen, stehe da wohl gerade auf dem Schlauch. db4o nutzt ausschließlich die Referenz um zu schauen, was in der Datenbank geupdated und was neu eingefügt werden muss. equals nützt da ja nichts.

In ORMs sind Referenzen nutzlos, schliesslich haben Objekte die nur in der DB "existieren" keine Referenz.

Hm, mal anders gefragt. Du hast 100 Objekte des gleichen Typs in deiner Datenbank, diese haben auch noch den gleichen Inhalt. Jetzt speicherst du ein weiteres, neues Objekt in deiner Datenbank, welches wieder vom gleichen Typ ist und wieder den gleichen Inhalt hat (also praktisch 101 gleiche Objekte in der DB). Dann holst du alle 101 Objekte aus der DB heraus und vergleichst die Referenz (==, nicht equals) von allen 101 erhaltenen Objekten mit dem Objekt, welches du gerade abgespeichert hast. Ist der Vergleich in Hibernate dann exakt 1 mal true? So wäre es in db4o.

Ja so wäre das in Hibernate/EclipseLink/JPA.

Jetzt frag ich mal andersrum: Wie legt man in db4o die Objektidentität fest?
Wie geht man mit ValueObjects um?

Weißt du, seit wann Hibernate in seiner Reinform das kann? Dann muss ich hier veraltete Informationen haben.

Das war schon 2007 so, k.A. seit wann genau.
Woher hast du eigentlich deine info zu Hibernate?

Mit RDBMS kenne ich mich ausnahmsweise sehr gut aus, aber ich weiß nicht genau, wie mir das hier weiterhilft Mich interessiert vor allem, wie die einzelnen Systeme aus logischer Sicht identische Objekte in- und außerhalb der DB "abgleichen". db4o kennt lediglich "store" und nichts anderes (das ist das, was bei Hibernate saveOrUpdate heißt) und dort geht das eben über die Referenzen. Dass Hibernate keine Objekte, sondern Zeilen in einem RDBMS speichert ist mir schon klar, da kann man schlecht Referenzen vergleichen. Dafür muss wahrscheinlich dann die Id herhalten.

Da ist doch gut

ORM brauchen eine ID für Entitäten, diese kann ein einfacher int sein, oder ein zusammengesetzter Schlüssel, der durch seine eigene Klasse repräsentatiert wird.