Hibernate: Löschen vor Speichern

Status
Nicht offen für weitere Antworten.

The_S

Top Contributor
Hi-Ho,

ich habe eine Tabelle mit einer UniqueConstraint. Aus dieser Tabelle soll in einem Atemzub (in einer Transaktion) Zeilen gelöscht und wieder hinzugefügt werden. Wenn ich jetzt blöderweise über entityManager.remove eine Zeile lösche, und dann später wieder eine Zeile mit der selben UniqueConstraints hinzufüge, fliegt das Ganze auf die Schnauze, weil Hibernate scheibar zuerst alle inserts (entityManager.persist) ausführt und dann erst deletet. Es kann aber sein, dass ein UniqueConstraint zuerst gelöscht und dann wieder hinzugefügt wird (nein, ich hab mir dieses Szenario nicht ausgedacht, ich darf es nur ausbaden). Wie bringe ich Hibernate bzw. Standard-JPA dazu, dass zuerst gelöscht und dann hinzugefügt wird?

Danke!
 

The_S

Top Contributor
ungünstig. Wir haben momentan eher eine ... naja ... sagen wir mal: Notlösung am laufen :oops: => Kein Webserver, WebService wird über Java-6 WebService ohne Server realisiert, Transaktionsmanagment wird in der WebService-Methose manuell "angeregt". Diese WebService Methode delegiert die Arbeit an untergeordnete Methoden, die sich um das eigentliche Löschen und Schreiben kümmern. Die WebService Methode ist nur für das Transaktionsmanagement und Konvertierung des Rückgabewerts der untergordneten Methode zuständig. Somit kann ich kein session.flush() Aufrufen, bevor nicht die komplette Arbeit erledigt wurde.
 

The_S

Top Contributor
Nein, kannte ich nicht. Danke, werde ich mir mal durchlesen. Es kann aber nicht sein, dass sich einfach nicht die Reihenfolge der Transaction gemerkt wird. Also so langsam aber sicher sehe ich in Hibernate (ein bisschen), aber vor allem in JPA mehr Zusatzarbeit als Erleichterung.
 
S

SlaterB

Gast
wenn du die Wahl hättest, es anders zu implementieren,
dann müsste doch irgendwie auch die Möglichkeit bestehen, ein flush auszulösen,

der Aufrufer muss ja nicht direkt selber das Session-Objekt in die Finger bekommen,
sondern nur eine bestimmte Methode 'nunLoeschIchNichtMehr()' aufrufen, die intern dann zum flush() führt
 

The_S

Top Contributor
Das hätte eine ziemlich große Umstellung unserer Struktur zur Folge. Ich werde es jetzt wohl auf zwei Methoden ausweiten und zwei Transaktionen öffnen/schließen. Ist zwar besch*****, aber was will man machen.

Ich werde wohl in allen zukünftigen Projekten darauf beharren, unbedingnt nicht mit Hibernate/JPA zu arbeiten, bis diese Projekte endlich mal ihre Kinderschuhe verlassen haben. :noe:
 

byte

Top Contributor
Irgendwie verstehe ich das Problem nicht so ganz. Warum kannst Du kein session.flush() machen?
 

The_S

Top Contributor
Zum Einen will ichs nicht machen, weil es einfach nur Unfug ist, wenn meine Statements nicht in der Reihenfolge abgearbeitet werden, in der ich sie aufrufe.

Ansonsten sieht meine Methode bspw. so aus:

Java:
@WebMethod
public String deleteAndInsertSomething(String something) {

  // Fürs Exceptionhandling bin ich grad zu faul
  beginTransaction();
  facade.deleteAndInsertSomething(something);
  commitTransaction();
}

Beide Aktionen, löschen und einfügen, werden aber in facade.deleteAndInsertSomething ausgeführt. Dort möchte ich (und auch eigentlich sonst niemand hier) aber kein Transaktionsmanagement haben.

Trotzdem danke für deine/eure Antworten.
 
M

maki

Gast
Was ich nicht verstehe wieso kein Update verwendet wird, sondern mit "Gewalt" erst die Datensätze gelöscht werden sollen die sofort wieder hinzugefügt werden sollen.
 

The_S

Top Contributor
Es werden mehrere Datensätze bearbeiten. Nicht alle, die hinzugefügt werden, müssen auch schon vorhanden sein. Das bedeutet Aufwand, da jeder Datensatz einzeln geprüft werden müsste. Zum Anderen schlägt das Einfügen aufgrund eines UniqueKeys fehl. Die Tabelle verfügt aber noch über weitere, nicht eindeutige Felder + einer ID. Es ist für die Anwendung an dieser Stelle zwingend erforderlich, dass eine neue ID generiert wird.
 

byte

Top Contributor
Zum Einen will ichs nicht machen, weil es einfach nur Unfug ist, wenn meine Statements nicht in der Reihenfolge abgearbeitet werden, in der ich sie aufrufe.

Ansonsten sieht meine Methode bspw. so aus:

Java:
@WebMethod
public String deleteAndInsertSomething(String something) {

  // Fürs Exceptionhandling bin ich grad zu faul
  beginTransaction();
  facade.deleteAndInsertSomething(something);
  commitTransaction();
}

Beide Aktionen, löschen und einfügen, werden aber in facade.deleteAndInsertSomething ausgeführt. Dort möchte ich (und auch eigentlich sonst niemand hier) aber kein Transaktionsmanagement haben.

Trotzdem danke für deine/eure Antworten.

Moment mal. Ein Session#flush() hat nichts mit Transaktionsmanagement zu tun. Wenn Du in deleteAndInsertSomething() nach dem Delete ein flush() machst, wird doch lediglich das SQL rausgeschickt. Die Transaktion wird nicht committed. Du kannst locker mehrmals in der gleichen Transaktion flushen. Ich sehe also das problem hier nicht. Denn genau für sowas ist flush() doch da. :eek:
 
M

maki

Gast
Es werden mehrere Datensätze bearbeiten. Nicht alle, die hinzugefügt werden, müssen auch schon vorhanden sein. Das bedeutet Aufwand, da jeder Datensatz einzeln geprüft werden müsste. Zum Anderen schlägt das Einfügen aufgrund eines UniqueKeys fehl. Die Tabelle verfügt aber noch über weitere, nicht eindeutige Felder + einer ID. Es ist für die Anwendung an dieser Stelle zwingend erforderlich, dass eine neue ID generiert wird.
Ok, verständlich.

Die Reihenfolge wird von hibernate selbst "optimiert", um sich unnötige SQl Abfragen (und den damit verbundenen Overhead) zu ersparen, d.h. Hibernate wird meckern wenn es merkt dass ein Datensatz zuerst gelöscht werden soll nur um danach wieder eingefügt zu werden.

Könnte da falsch liegen, aber ein flush sollte keine Transaktion commiten.
 

The_S

Top Contributor
Moment mal. Ein Session#flush() hat nichts mit Transaktionsmanagement zu tun. Wenn Du in deleteAndInsertSomething() nach dem Delete ein flush() machst, wird doch lediglich das SQL rausgeschickt. Die Transaktion wird nicht committed. Du kannst locker mehrmals in der gleichen Transaktion flushen. Ich sehe also das problem hier nicht. Denn genau für sowas ist flush() doch da. :eek:

Sorry, im Eifer des Gefechts habe ich wohl nicht genau hingesehen/nachgedacht. Eigentlich widerstrebt es mir nur, ein flush() auszuführen. Warum können nicht einfach die Statements in der Reihenfolge abgesetzt werden, in der ich sie aufrufe? Naja gut, danke nochmals, ich werde es mal mit nem flush (widerwillig ;) ) versuchen.
 

byte

Top Contributor
Sorry, im Eifer des Gefechts habe ich wohl nicht genau hingesehen/nachgedacht. Eigentlich widerstrebt es mir nur, ein flush() auszuführen. Warum können nicht einfach die Statements in der Reihenfolge abgesetzt werden, in der ich sie aufrufe? Naja gut, danke nochmals, ich werde es mal mit nem flush (widerwillig ;) ) versuchen.

Es wird sicherlich Gründe geben, warum die Reihenfolge der SQL-Statements so gewählt wurde wie sie sind (siehe maki). Für genau solche Fälle, wo einem das nicht passt, gibt es Session#flush().
Ich verstehe Deine Bedenken nicht gegen den Aufruf von flush(). Nenn mir mal nen plausiblen Grund, was gegen flush() spricht!
 
S

SlaterB

Gast
> Nenn mir mal nen plausiblen Grund, was gegen flush() spricht!

wenn es keinen gäbe, wieso ist das dann nicht automatisch zumindest bei Session.delete() eingebaut? ;)
wenn man geänderte Objekte in der Session hat, die später noch weiter geändert werden,
werden unnötig Zwischenzustände in die DB geschrieben

-----

einen Optimierungssinn zu delete vor insert ist mir auch noch nicht bekannt,
für mich ein Bug
 

The_S

Top Contributor
Es wird sicherlich Gründe geben, warum die Reihenfolge der SQL-Statements so gewählt wurde wie sie sind (siehe maki). Für genau solche Fälle, wo einem das nicht passt, gibt es Session#flush().
Ich verstehe Deine Bedenken nicht gegen den Aufruf von flush(). Nenn mir mal nen plausiblen Grund, was gegen flush() spricht!

Sorry, hatte ich schon wieder übersehen (ihr schreibt aber auch verdammt schnell ;) ). Aber ich schließe mich da einfach mal der Aussage von Slater an :D .
 

byte

Top Contributor
> Nenn mir mal nen plausiblen Grund, was gegen flush() spricht!

wenn es keinen gäbe, wieso ist das dann nicht automatisch zumindest bei Session.delete() eingebaut? ;)

Das wäre doch sehr sinnfrei.

Es ist natürlich schneller, alle Deletes / Inserts am Stück zu machen, daher sollte man natürlich nicht wahllos alles sofort flushen. Aber in diesem speziellen Fall ist halt flush() die Lösung. Daher wollte ich von Hobbit wissen, was er in diesem speziellen Fall gegen flush() hat!
 
Zuletzt bearbeitet:

The_S

Top Contributor
Also es funktioniert auch mit flush(). Soweit so gut. Danke für den Hinweis. Trotzdem habe ich was dagegen, wenn mich eine automatisierte Optimiererei, die ich nicht eingeschaltet/gewollt/... habe, in meiner Arbeit zurückwirft bzw. wertvolle Zeit kostet. Wenn schon automatisch optimiert wird, dann muss auch sichergestestellt werden, dass es auch funktioniert, wenn es ohne Optimierung geht. just my 2 cents ;)
 
M

maki

Gast
Die automatische Optimierung funktioniert, ohne sie wäre Hibernate bzw. die meisten ORM nicht einsetzbar weil zu langsam.
Du hast einen atypischen Fall und deswegen musst du flush einsetzen, ist oft der Fall bei atypischen Fällen.
 

byte

Top Contributor
Hibernate ist ein extrem mächtiges Framework, das aber auch extrem viel Knowhow erfordert, um es richtig einsetzen zu können.

Wenn Du weisst, wie Hibernate funktioniert, dann kannst Du extrem effizient Persistenz implementieren. Aber bis man wirklich von sich behaupten kann, ein Hibernate Experte zu sein, vergehen diverse Monate.

Hibernate ist keine einfache Lib, mit der jeder Nub Persistenz realisieren kann.

Wenn Du der Meinung bist, Hibernate macht Dir mehr Probleme als es löst, dann stehts Dir frei, das alles selbst per JDBC zu implementieren. Ich bezweifel aber mal stark, dass Du damit die gleiche Effizienz erreichen wirst.
 

The_S

Top Contributor
Die automatische Optimierung funktioniert, ohne sie wäre Hibernate bzw. die meisten ORM nicht einsetzbar weil zu langsam.

Och ... naja ... wenn ich mir da teilweise die logs ansehe ... *grusel*. Ansich ist es schon ne gute Sache, aber für meine Bedürfnisse nach wie vor zu unausgereift.
 
S

SlaterB

Gast
> Du hast einen atypischen Fall und deswegen musst du flush einsetzen, ist oft der Fall bei atypischen Fällen.

diese Interpretation kann ich nicht nachvollziehen,

klar ist der Fall atypisch,
aber genauso atypisch ist es, mit Quicksort eine sortierte Liste zu sortieren, was dann zur schlechtestmöglichen Laufzeit führt,
dass aber die Sortierung dann mit Fehler scheitert, wäre doch wohl undenkbar

genauso muss auch Hibernate sein, vielleicht langsam, aber auf jeden Fall korrekt, gerade wenn der User so schlau ist,
in korrekter Reihenfolge einzufügen und zu entfernen

> Wenn Du der Meinung bist, Hibernate macht Dir mehr Probleme als es löst, dann stehts Dir frei, das alles selbst per JDBC zu implementieren.
> Ich bezweifel aber mal stark, dass Du damit die gleiche Effizienz erreichen wirst.

das ist ja etwas billig, man darf doch wohl im neutralen Ton Kritik anbringen,
die dann wenn überhaupt, mit richtigen Argumenten begegnet werden muss
 
Zuletzt bearbeitet von einem Moderator:

byte

Top Contributor
Och ... naja ... wenn ich mir da teilweise die logs ansehe ... *grusel*. Ansich ist es schon ne gute Sache, aber für meine Bedürfnisse nach wie vor zu unausgereift.
Hast du mal ein Beispiel, wovon Du sprichst?
Wie jedes Framework ist auch Hibernate nicht perfekt. Aber angesichts der komplexen Thematik (Datenbanken), macht Hibernate schon einen extrem guten Job. Zumindest gibts in meinen Augen keine Alternative, oder kennt ihr eine?
 
M

maki

Gast
Kann byto da nur zustimmen, HIbernate verwenden will gelernt sein, denn wenn Hibernate etwas nicht ist, dann "non-invasive" (auch wenn es immer so angepriesen wird) oder gar intuitiv, aber dafür ist das ganze Thema ORM viel zu komplex.

Die Lernkurve ist steil und auch lang, man wird immer wieder überrascht.

Gehen wir nochmal kurz auf das atypische an deinem Anwendungsfall ein:
Es werden mehrere Datensätze bearbeiten. Nicht alle, die hinzugefügt werden, müssen auch schon vorhanden sein. Das bedeutet Aufwand, da jeder Datensatz einzeln geprüft werden müsste.
Hibernate macht genau eine Abfrage (in Java, nicht der DB) um zu Wissen ob ein Objekt neu ist oder bereits in der DB abgelegt war, nämlich die ID prüfen.
Wenn man das weiss strukturiert man seine Logik so, um daraus einen Vorteil zu gewinnen.
 

The_S

Top Contributor
Wenn Du weisst, wie Hibernate funktioniert, dann kannst Du extrem effizient Persistenz implementieren. Aber bis man wirklich von sich behaupten kann, ein Hibernate Experte zu sein, vergehen diverse Monate.

Das bin ich auch garantiert nicht und möchte ich zum jetztigen Zeitpunkt auch gar nicht sein ;) .

Wenn Du der Meinung bist, Hibernate macht Dir mehr Probleme als es löst, dann stehts Dir frei, das alles selbst per JDBC zu implementieren. Ich bezweifel aber mal stark, dass Du damit die gleiche Effizienz erreichen wirst.

Wie bereits hier erwähnt (aber evtl. mit etwas zu wenig Nachdruck): Hibernate ist größtenteils akzeptabel, auch wenn ich nicht verstehe, warum manche Dinge nicht gleich richtig implementiert wurden bzw. es so unnötig komplex und aufgebläht ist. Hauptproblem habe ich mit der JPA-Spezifikation, die ja wahrlich doch sehr beschränkt ist. Wir programmieren zwar momentan mit Hibernate, das ist aber nur eine temporäre Lösung bis der SAP NetWeaver steht - und der hält sich so genau an den schlechten JPA-Standard, mit dem man bestenfalls irgendwelche 08/15 Hobbyprojekte realisieren möchte. Ich werf nur mal Dinge in den Raum wie: Keine Berechnungen im NamedQuery, bei Aufruf eines Konstruktors darf kein ORDER BY dabei sein, Left Outer Joins über Tabellen, die nicht in der Entity referenziert sind, Foreign Keys die Gleichzeitig auch als Primary Key fungieren sollen, ... Na klar umgeht Hibernate viele Probleme, aber eben nicht alle.

Zudem kommt es bei diesem Projekt sehr auf die Performance an - bevor ich stundenlang an einem NamedQuery tüftle und dann doch noch die Hälfte außerhalb des Querys in einer Java-Klasse erledigen muss, bin ich an dieser Stelle wirklich mit JDBC effizienter. Außerdem wird sich die Datenbank, die der Anwendung zugrunde liegt, ohnehin nie ändern. Aber da hat wohl eher unser Architekt gepennt ... :autsch:
 

byte

Top Contributor
klar ist der Fall atypisch,
aber genauso atypisch ist es, mit Quicksort eine sortierte Liste zu sortieren, was dann zur schlechtestmöglichen Laufzeit führt,
dass aber die Sortierung dann mit Fehler scheitert, wäre doch wohl undenkbar

genauso muss auch Hibernate sein, vielleicht langsam, aber auf jeden Fall korrekt, gerade wenn der User so schlau ist,
in korrekter Reihenfolge einzufügen und zu entfernen
Bei DB Statements spielt Performance eine sehr große Rolle. Hibernate optimiert hinsichtlich der Performance, was in diesem Fall Probleme bereitet. Hibernate bietet aber auch eine Lösung mittels flush(). Insofern ist das Problem neutralisiert.
Du schreibst, Hibernate muss in jedem Fall fehlerfrei funktionieren. Wie soll das bitte gehen? Hibernate kann nicht jede Exception der DB im Vorraus berechnen und entsprechend darauf reagieren bzw. sie verhindern.
Zumal auch nicht jede DB gleich ist. Bei Oracle gibts z.b. die Möglichkeit, Constraints erst beim Commit der Transaktion zu checken. Da würde o.g. Problem gar nicht auftreten.
 

The_S

Top Contributor
Hibernate macht genau eine Abfrage (in Java, nicht der DB) um zu Wissen ob ein Objekt neu ist oder bereits in der DB abgelegt war, nämlich die ID prüfen.
Wenn man das weiss strukturiert man seine Logik so, um daraus einen Vorteil zu gewinnen.

Womit wir beim nächsten Problem des Projekts wären. Bei einer sehr alten Anwendung, die über 10 Jahre lang gewachsen ist, wird der Datenbanktreiber nicht mehr offiziell unterstützt. Es ist nur noch eine Frage der Zeit, bis uns das Ding um die Ohren fliegt. Ziel war/ist es jetzt "auf die schnelle" ein anderes Backend für diese Anwendung aufzubauen. Deshalb müssen wir uns an dieser Stelle an die Logik der alten Applikation halten. Bei einer späteren Neuentwicklung der gesamten Anwendung sieht die Welt schon wieder ganz anders aus. Da gebe ich dir dann natürlich recht. Aber momentan ist das einfach nicht anders zu realisieren.
 

The_S

Top Contributor
Hast du mal ein Beispiel, wovon Du sprichst?
Wie jedes Framework ist auch Hibernate nicht perfekt. Aber angesichts der komplexen Thematik (Datenbanken), macht Hibernate schon einen extrem guten Job. Zumindest gibts in meinen Augen keine Alternative, oder kennt ihr eine?

Sorry, wir haben unmengen an NamedQuerys in diesem Projekt und sind momentan ein wenig hintendran. Da habe ich leider keine Zein einen konkreten Fall rauszusuchen. Aber wenn mal wieder mehr Zeit ist und dieser Thread nicht bei mir in Vergessenheit geraten sollte, werde ich mich mal auf die Suche machen.

Ansonsten muss ich Slater schon rechtgeben. Hibernate muss nicht in jedem Fall fehlerfrei funktionieren - das macht keine Software und verlangt auch niemand. Aber es sollte keinen korrekten Code doch "Optimierung" verfälschen.

So, ich mach jetzt erstmal Feierabend. Bis Dienstag ;)
 
S

SlaterB

Gast
Du schreibst, Hibernate muss in jedem Fall fehlerfrei funktionieren. Wie soll das bitte gehen? Hibernate kann nicht jede Exception der DB im Vorraus berechnen und entsprechend darauf reagieren bzw. sie verhindern.
ist das ein Scherz? habe ich auch geschrieben, dass ein Sortieralgorithmus gegen OutOfMemoryError sicher sein muss oder konkurrierende Veränderung der Objekte zur Laufzeit?
oder muss sich nicht eher ein Sortieralgorithmus genau um seine Sortierung kümmern und Hibernate genau um seine Inserts..
bin etwas sprachlos ob dieser Nachfrage..

Bei DB Statements spielt Performance eine sehr große Rolle. Hibernate optimiert hinsichtlich der Performance, was in diesem Fall Probleme bereitet. Hibernate bietet aber auch eine Lösung mittels flush(). Insofern ist das Problem neutralisiert.
dieser Punkt wäre akzeptabel, etwa wenn das irgendwo in der 500 Seiten-Anleitung von Hibernate oder in der Doku von flush() beschrieben wäre
oder wenn es eine Einstellung gäbe 'lieber sicher statt schnell' so wie die einigermaßen bekannten Isolationslevel einer Transaktion

aber wenn nichtmal ein solcher möglicher konkreter Fehlerfall irgendwo von Hibernate dokumentiert ist,
dann meine ich, muss man doch eher von einem Bug ausgehen

Zumal auch nicht jede DB gleich ist. Bei Oracle gibts z.b. die Möglichkeit, Constraints erst beim Commit der Transaktion zu checken. Da würde o.g. Problem gar nicht auftreten.
ein Grund mehr für Einstellungen,
kein Grund für Fehlerverhalten

zumal ich weiterhin nicht sehe, wieso ein Delete vor oder nach dem Insert etwas optimiert
 
M

maki

Gast
Womit wir beim nächsten Problem des Projekts wären. Bei einer sehr alten Anwendung, die über 10 Jahre lang gewachsen ist, wird der Datenbanktreiber nicht mehr offiziell unterstützt. Es ist nur noch eine Frage der Zeit, bis uns das Ding um die Ohren fliegt. Ziel war/ist es jetzt "auf die schnelle" ein anderes Backend für diese Anwendung aufzubauen. Deshalb müssen wir uns an dieser Stelle an die Logik der alten Applikation halten. Bei einer späteren Neuentwicklung der gesamten Anwendung sieht die Welt schon wieder ganz anders aus. Da gebe ich dir dann natürlich recht. Aber momentan ist das einfach nicht anders zu realisieren.
Aha, da liegt der Hase im Pfeffer... retrofitting von Altwanwendungen ist immer nur ein großer Brocken aus Kompromissen, deswegen wollen ja alle zu den sog. Greenfield Projekten :D

Persönlich bin ich kein Freund davon Hibernate/JPA auf bestehe DB Schema und Klassenmodelle aufzuzwängen, da ist iBatis imho besser geeignet da flexibler (weil kein echtes ORM).

Die von dir angesprochenen Probleme mit JPA sehe ich ähnlich, und mittlerweile ist JPA nicht unumstritten, vor allem wenn man es mit bereits bestehenden ORM Lösungen wie JDO (seit 1999) vergleicht, hinkt es einfach.
Anscheinend wird JPA durch Marktinteressen von RDBMS Herstellern getrieben, soz. durch Politik gertrieben.

Nachtrag: Viele Probleme mit Hibernate (oder ORM im allgemeinen) haben ihre Ursache darin, dass man selbst immer noch zusehr in RDBMS Dimensionen denkt, mit ORM ist die DB zweitrangig, das ORM ist Herr der Daten, und damit auch über die Reihenfolge von irgendwelchen low-level SQL Abfragen ;)
 
Zuletzt bearbeitet von einem Moderator:

The_S

Top Contributor
Persönlich bin ich kein Freund davon Hibernate/JPA auf bestehe DB Schema und Klassenmodelle aufzuzwängen, da ist iBatis imho besser geeignet da flexibler (weil kein echtes ORM).

Sag das mal unserem Architekten. Ist ja nicht so, dass wir bereits Projekterfahrung mit iBatis haben. Aber nein, SAP und JPA ist das Allheilmittel, weshalb das Projekt mit aller Gewalt in dieses Korsett gezwungen werden muss :noe:
 

KSG9|sebastian

Top Contributor
Also bestehende Anwendungen auf JPA umzubauen halte ich für fragwürdig.

maki hat gesagt.:
Nachtrag: Viele Probleme mit Hibernate (oder ORM im allgemeinen) haben ihre Ursache darin, dass man selbst immer noch zusehr in RDBMS Dimensionen denkt, mit ORM ist die DB zweitrangig, das ORM ist Herr der Daten, und damit auch über die Reihenfolge von irgendwelchen low-level SQL Abfragen

Man MUSS in RDBMS-Dimensionen denken. Ein ORM-Framework hilft einem mit einer Datenbank zu kommunizieren, allerdings nimmt es einem das Denken nicht ab. Und genau das ist oft der Grund warum es zu Performanceproblemen kommt.
So nach dem Motto "Die Datenbank, der komische schwarze Kasten im Rechenzentrum, ist mir doch Schnuppe. Was kümmern mich Indizes, Normalisierung, Optimierung von Querys".

In größeren Projekten muss enorm darüber nachgedacht werden wie man z.B. Abfragen macht, lazy-loading ist der nächste Streitfaktor: Sinnvoll eingesetzt ein tolles Feature, falsch eingesetzt führt es nur zu Problemen (n+1-Problem u.s.w.).

Allerdings muss ich vielen hier recht geben, JPA 1.0 hinkt einfach ewig hinterher. JPA 2.0 schafft bei manchen Problemen abhilfe, ist aber imho für Großprojekte nur schwer einsetzbar da einfach sehr viel fehlt.
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
T JPA2/Hibernate: Many-to-Many-Relation wird u.a. beim löschen nicht aktualisiert Data Tier 14
G Hibernate: many-to-one - Verwaiste Datensätze löschen Data Tier 2
S Hibernate: Objekt aus Liste löschen Data Tier 3
I Hibernate / JPA: Eine Datenbank und pro User ein Schema Data Tier 9
T Hibernate/Spring JPA: eigene ID generieren Data Tier 5
Avalon @ManyToOne Hibernate oder JPA? Data Tier 5
D Hibernate Hibernate mit MariaDB Data Tier 1
ToBJo Hibernate Glassfish deploy mit Hibernate schlägt fehl Data Tier 1
C JPA Hibernate Map<String,String> richtig mappen Data Tier 2
S JPA Hibernate Search & EclipseLink (oder OpenJPA) Data Tier 0
R JPA Probleme mit Wechsel von EclipseLink auf Hibernate Data Tier 4
ARadauer Hibernate Entität readonly laden... Data Tier 1
G Hibernate SQL in Hibernate: Keine Parameter mit Index? Data Tier 2
P Wildfly + Hibernate + SQL Server Data Tier 0
E JPA Hibernate Query mit Timestamp hat seltsames Verhalten Data Tier 1
M Eclipse 4 RCP Hibernate Problem Data Tier 3
C Hibernate ProgressBar updaten mit Daten aus Hibernate Data Tier 4
B Hibernate und MySQL testen Data Tier 8
I Hibernate HQL: generiertes SQL ausgeben Data Tier 1
R mapping-file für hibernate zum Überschreiben der Annotationen Data Tier 7
R Hibernate Hibernate und Logback Data Tier 2
R Hibernate möchte Schema zwei mal undeployen Data Tier 2
F Hibernate Hibernate / JPA Data Tier 4
E Hibernate: Session vs EntityManager Data Tier 3
C Hibernate Hibernate Code Generation Data Tier 3
S Hibernate Mehrfachverbindung mit Hibernate Data Tier 3
M Hibernate Einstiegsfrage Data Tier 5
M Exception in thread "main" org.hibernate.MappingException: java.lang.ClassNotFoundException: Message Data Tier 4
S Hibernate Einstieg in Hibernate 3.2 sinnvoll? Data Tier 8
P JPA Eigene Vererbungsstrategie mit JPA / Hibernate Data Tier 2
J Hibernate Problem bei Master-Detail-Tabellen Data Tier 5
Y Jboss seam-hibernate-jpa Data Tier 5
RaoulDuke Hibernate Map<String,String> mit Annotations mappen Data Tier 2
M Hibernate Hibernate with GWT Data Tier 4
C Hibernate JPA mysql db erstellen Data Tier 4
M Hibernate Hibernate liest Daten zu oft aus! Data Tier 16
pg1337 Hibernate Fragen Data Tier 11
D Probleme bei Left Joins mit Hibernate createCriterias() Data Tier 2
D Hibernate probleme mit Verlinkungstabelle Data Tier 4
2 Hibernate Annotations Data Tier 7
G Hibernate select update no wait Data Tier 8
Z Hibernate: Many-To-Many nur eine bestimmte Spalte Data Tier 3
K Hibernate - Envers - Erzeugung der SQL Skripte Data Tier 4
G Hibernate 1:n Beziehung mit Vererbung Data Tier 5
D Hibernate-Criteria-API (Projections und MAX-Funktion) Data Tier 6
L Hibernate: failed to lazily initialize a collection of role Data Tier 3
S Hibernate hibernate.cfg.xml Data Tier 14
D JPA vs Hibernate.cfg und Entitymanager Data Tier 6
H Hibernate - Mapping für Enumeration Data Tier 1
R Hibernate Criteria Abfrageproblem Data Tier 2
A Hibernate und jdbc zusammen Data Tier 4
D Mit Hibernate aus JUnit ein DB-Schema erzeugen Data Tier 6
S [Hibernate] No Persistence provider for EntityManager Data Tier 5
B Problem mit org.hibernate.LazyInitializationException Data Tier 11
G Hibernate HQL und Interface Data Tier 4
G JSF Hibernate no session or session was closed Data Tier 12
S (Hibernate) Mapping einer Datenbanktabelle mit mehreren Fremdschlüssel Data Tier 7
X [Hibernate] Zusammengesetzte Entities möglich? Data Tier 7
N Hibernate Fake? Data Tier 2
S Problem beim Insert mit Hibernate Data Tier 9
V Hibernate Projection Data Tier 2
T org.hibernate.impl.SessionFactoryImpl Memory Leak Data Tier 10
G Hibernate Composite key Data Tier 11
X [Hibernate] Connection Pool - MinSize ? Data Tier 2
R Hibernate Criteria OR Data Tier 2
T hibernate/jpa abgefragte Listen immer mit Null-Werten gefüllt Data Tier 8
X [Hibernate] Anderen Connection Pool - Vorschläge? Data Tier 3
ARadauer Hibernate DDL Loggen Data Tier 6
G Hibernate abfrage Collection Data Tier 3
X [Hibernate] ReverseEngineering - Eigene Strategy verwenden? Data Tier 3
R Hibernate Criteria .group größer als Data Tier 5
R Hibernate daten laden Data Tier 7
H [Hibernate]1:1 Beziehung Data Tier 8
H [Hibernate]No CurrentSessionContext configured! Data Tier 6
X [Hibernate] Lässt sich die Dauer eines SELECTs loggen? Data Tier 4
R Hibernate n:n Relationtabelle mit Date Data Tier 3
H [Hibernate] Unknown Entity Data Tier 3
H [Hibernate] Configuration Data Tier 3
C [Hibernate] Generierung von hbm.xml to Java Data Tier 4
lumo Eclipse & JPA & Hibernate & Derby Data Tier 5
J Zufallsauswahl aus ResultList bei JPA(Hibernate) / Performance Data Tier 3
M Hibernate: Datum 0001-01-01 erzeugt null-Datum Data Tier 4
G Datenbankzugriff mit Hibernate Data Tier 7
Y Hibernate - Angabe des Schemas Data Tier 6
LadyMilka (Hibernate) in Criteria implizierter Join durch Subquery's Data Tier 8
M Hibernate Mehr als 1 Object speichern? Data Tier 18
M Unerklärliche Hibernate Exception Data Tier 20
LadyMilka (Hibernate) subquery in FROM-Clause Data Tier 9
haemi Viele DTOs in hibernate IdentityMap Data Tier 3
LadyMilka (hibernate) UNION dem Dialekt hinzufügen Data Tier 3
M Hibernate + Oracle 10g XE Data Tier 3
lumo Hibernate - entity class not found Data Tier 5
P SQL PRoblem Hibernate? Data Tier 8
J Vererbung mit JPA / Hibernate - pro/contra Data Tier 3
T JBoss/Hibernate: Abfrage dauert lang + hohe CPU? Data Tier 19
7 Hibernate-Abfrage (SubSelect im FROM) Data Tier 2
G Layer für Datenbankzugriff Hibernate Data Tier 5
G Hibernate Zwischentabelle Data Tier 2
Java.getSkill() Hibernate und Spalte vom Typ xml Data Tier 6
G Hibernate 0...1 : 1 Beziehung Data Tier 6

Ähnliche Java Themen


Oben