# JPA 2.0, wann eigentlich genau?



## -MacNuke- (25. Jun 2009)

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 (25. Jun 2009)

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- (25. Jun 2009)

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 (25. Jun 2009)

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 (25. Jun 2009)

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 (25. Jun 2009)

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- (25. Jun 2009)

Noctarius hat gesagt.:


> 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 (25. Jun 2009)

Noctarius hat gesagt.:


> 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- (26. Jun 2009)

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 (26. Jun 2009)

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- (26. Jun 2009)

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 (26. Jun 2009)

... 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 (26. Jun 2009)

> 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- (26. Jun 2009)

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


----------



## timowest (5. Jul 2009)

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 (5. Jul 2009)

timowest hat gesagt.:


> 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 (5. Jul 2009)

timowest hat gesagt.:


> 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 (6. Jul 2009)

maki hat gesagt.:


> 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- (6. Jul 2009)

timowest hat gesagt.:


> 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 (7. Jul 2009)

-MacNuke- hat gesagt.:


> 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
> ...



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.


----------

