JPA 2.0, wann eigentlich genau?

[-MacNuke-]

Hiho.

Ich arbeite zur Zeit an einem Projekt, welches dann mit JPA realisiert wird. In JPA 2.0 soll es denn ja mehrere Verbesserungen geben, u.a. auch eine Criteria-API, wie sie auch in Hibernate zu finden ist.

Ich finde nur nicht wann diese erscheinen soll, und wann die größeren JPA-Provider diese umsetzen können.

Gibt's da irgendwo Infos dazu?

Als Ersatz für die Criteria-API gibt es ja zum Beispiel auch QueryDSL. Das würde ich dann ja "zur Not" nutzen, aber wenn es irgendwann mal was offizielles gibt, wäre das schon praktisch

 

[Noctarius]

JPA 2.0 Spec. ist bereits fertig und die Referenzimplementierung von Eclipselink ist im Release Candidate Status soweit ich weiß. Sollte also nicht mehr solange dauern.

Die Criteria API ist wie die in Hibernate leider nicht so richtig gelungen. Die von Torque war / ist schon besser aber auch noch nicht wirklich optimal. Leider alles nicht wirklich typensicher implementiert.

 

[-MacNuke-]

Ja, das hatte ich schon gelesen und Querydsl ist hier ja sicher.
Aber das von JPA 2.0 ist immer noch besser als Strings zusammenzufummeln xD

 

[Noctarius]

Naja die Criteria API von JPA2 ist auch String basiert. Da kannst auch gleich mit JPQL nen Query bauen. Ändert sich durch Refactoring der Klassenname ist die Kacke am Dampfen

 

[byte]

Dazu kommt die Tatsache, dass HQL / JPQL ausdrucksstärker ist als die Criteria API. Mag sein, dass es bloß Unkenntnis meinerseits ist, aber ich habe viele HQL Queries, wo ich nicht wüsste, wie ich die mit Criteria umsetzen könnte.

 

[Noctarius]

Criteria ist einmal Eingewöhnen und dann ist die API quasi selbsterklärung und auch sofort verständlich wenn du irgendwo ein "Query" siehst.

 

[-MacNuke-]

Naja die Criteria API von JPA2 ist auch String basiert. Da kannst auch gleich mit JPQL nen Query bauen. Ändert sich durch Refactoring der Klassenname ist die Kacke am Dampfen

Naja, aber diese Strings sind ja "nur" auf Klassen- und Feldnamen bezogen.

Ich meine damit eher so Sachen wie das setzen von "Standard"-Eigenschaften. z.B. Spalte deleted oder so. Da soll z.B. immer ein False drinnen stehen. Mit Strings muss man da fummeln, und immer aufpassen, dass dort auch ein richtiger Wert steht. Eine Criteria-Query brauchst du nur übergeben und hängst die entsprechenden Typen ran.

Das ist nur ein Beispiel. Weiterführend währe dann nutzerdefinierte Sortierungs- und Filteroptionen. Statt irgendwelche Strings zusammenzufummeln, arbeitet man hier mit normalen Sachen, die man an eine Criteria anfügt.

Das gerade für statische Sachen "normales" JPAQL einfacher und "schneller" sind, ist mir schon klar.

 

[byte]

Criteria ist einmal Eingewöhnen und dann ist die API quasi selbsterklärung und auch sofort verständlich wenn du irgendwo ein "Query" siehst.

Für einfache Queries mag das zutreffen aber nicht mehr für komplexere Kombinationen aus Joins und/oder Subselects!

Wie sieht denn z.B. das Criteria für folgende HQL-Queries aus:

select distinct b
from A a
left join a.b b
where a.property = b.property

select new map(a.property as p1, b.property as p2, c.property as p3)
from A a
left join a.b b
left join b.c c

select
b.property1,
min(b.property2),
max(b.property2),
avg(b.property2),
from A a
left join a.b b
group by b.property1

select distinct a
from A a
left join fetch a.b b
where b.property in (
  select distinct d.property
  from C c
  left join c.d d
)

Edit: Solche Criteria Queries sind umständlich zu konstruieren und absolut unübersichtlich im Code zu überschauen. Kein Mensch blickt da nach nem Monat noch durch.

 

[-MacNuke-]

Naja, Criteria-Queries sind ja nun nicht dazu da um die normalen Queries zu ersetzen. Klar geht einiges mit den Normalen leichter und übersichtlicher. Aber wenn es darum geht zur Laufzeit Queries zusammenzubauen, geht es halt mit Criteria-Queries deutlich leichter.

 

[byte]

Jo hast schon recht. Eklig wirds nur, wenn man ein komplexes Query hat, das auch dynamisch zusammengesetzt wird. Da bevorzuge ich doch eher HQL ggü. Criteria.

 

[-MacNuke-]

Hab mir das ganze jetzt mal angesehen.

Also laut dem hier wird JPA 2.0 auch typsicher funktionieren, ähnlich wie Querydsl.
Java Persistence 2.0 Proposed Final Draft : Linda DeMichiel's Blog

Aber EclipseLink scheint noch nicht wirklich im Release Candidate Status zu sein. Wenn ich die "neuen" Sachen nutzen will fliegen mir NullPointer und "not Implemented" Meldungen nur so um die Ohren

Also wohl noch etwas warten. Die jetzige Criteria-API von JPA2 sieht aber etwas seltsam aus, finde ich

 

[byte]

... oder man pfeift auf die Spezifikation und nimmt einfach Hibernate.

Nichts gegen Spezifikationen, aber wenn ich meine Anforderungen damit nicht umsetzen kann, dann ist sie nutzlos.

 

[maki]

Nichts gegen Spezifikationen, aber wenn ich meine Anforderungen damit nicht umsetzen kann, dann ist sie nutzlos.

Genau so sieht's aus, JPA 1.0 war ein schlechter Witz, wie ich dann auch feststellen musste.

 

[-MacNuke-]

Das ist schon richtig. Ich arbeite mich gerade so mal breitflächig ein. Noch hab ich ein paar Tage zum probieren

 

[timowest]

Wir von Mysema arbeiten aktiv mit der JDO Gruppe zusammen um zumindest fuer JDO etwas Querydsl ähnliches zu standardisieren.

Bei JPA 2.0 waren wir leider zu spät dran und hatten keine starken Partner. JPA 2.0 Criteria queries sind sehr lang und die queries sind nicht wirklich typensicher.


Querydsl entwickelt sich neben den Standards von JPA und JDO, ist aber heute schon fuer JPA / Hibernate und JDO eine sehr gute und sichere Alternative um queries zu konstruieren.

Die erfolgreichsten Standards sind nicht Standards von Konsortien sondern Standards, die aus der Praxis gewachsen sind.

Welche Features fehlen eurer Meinung nach noch in Querydsl? Was wirkt zu kompliziert, was funktioniert nicht wirklich?

 

[Noctarius]

Welche Features fehlen eurer Meinung nach noch in Querydsl? Was wirkt zu kompliziert, was funktioniert nicht wirklich?

Habe mich bisher noch nicht damit auseinander gesetzt, werde es mir aber bei Gelegenheit mal ansehen und meine Meinung dazu kund tun

 

[maki]

Wir von Mysema arbeiten aktiv mit der JDO Gruppe zusammen um zumindest fuer JDO etwas Querydsl ähnliches zu standardisieren.

Hab mich nur oberflächlich mit JDO auseinandergesetzt, unterstützt Datanuclues schon die QueryDSL?

 

[timowest]

Hab mich nur oberflächlich mit JDO auseinandergesetzt, unterstützt Datanuclues schon die QueryDSL?

Querydsl unterstuetzt JDO(QL) und wurde gegen DataNucleus getestet. DataNucleus bietet noch kein Bundle, wo Querydsl dabei ist, aber die Kombination der beiden Module ist trivial.

Wir arbeiten mit DataNucleus aktiv zusammen um das Querydsl JDOQL-Modul weiter zu entwickeln und eventuell als Teil von JDO zu standardisieren.

 

[-MacNuke-]

Welche Features fehlen eurer Meinung nach noch in Querydsl? Was wirkt zu kompliziert, was funktioniert nicht wirklich?

Eigentlich gar nicht mal so sehr die Funktionen, auch wenn ich jetzt noch nicht tiefgründig damit gearbeitet habe.

Ich würde mir nur etwas mehr Dokumentation und Beispiele wünschen. Meine Versuche eine Abfrage mit mehreren WHERE Bedinungen zu erstellen endete in Try&Error, da die Doku schon bei einer Bedingung aufhört JOINs habe ich jetzt noch nicht probiert, aber auch dazu scheint sich die Doku auszuschweigen.

Also mindestens eine Doku in der Größe (ist ja nicht mal sooo viel):
Chapter 15. Criteria Queries

Solltet ihr schon haben, für etwas mehr "Beachtung", denke ich.

 

[timowest]

Ich würde mir nur etwas mehr Dokumentation und Beispiele wünschen. Meine Versuche eine Abfrage mit mehreren WHERE Bedinungen zu erstellen endete in Try&Error, da die Doku schon bei einer Bedingung aufhört JOINs habe ich jetzt noch nicht probiert, aber auch dazu scheint sich die Doku auszuschweigen.

Also mindestens eine Doku in der Größe (ist ja nicht mal sooo viel):
Chapter*15.*Criteria Queries

Solltet ihr schon haben, für etwas mehr "Beachtung", denke ich.

Stimmt. Ich werde die HQL und Criteria chapters als Basis fuer Beispiele nehmen, und sie in im nächsten Release in die Referenzdokumentation einfuegen.

Mehrere WHERE-Bedingungen können folgendermassen bestimmt werden

query.where(cond1, cond2, ...) // varargs

oder

query.where(cond1.and(cond2).and(...) ) //and-chaining

Generell ist das Querydsl HQL-Modul eine DSL-variante von HQL. Die keywords sind bis auf einige Ausnahmen dieselben.