Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » Querydsl
Querydsl [message #554763] Tue, 24 August 2010 07:09 Go to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
For those people wrestling with queries and the new CriteriaBuilder in JPA2. I decided to give Querydsl a try. Just FYI a query that selects on a name and a date range.

JPA2 using metaclasses:
CriteriaBuilder lCriteriaBuilder = lEntityManager.getCriteriaBuilder();
CriteriaQuery<Buyorder> lCriteriaQuery = lCriteriaBuilder.createQuery(Buyorder.class);
Root<Buyorder> lBuyorderRoot = lCriteriaQuery.from(Buyorder.class);
lCriteriaQuery = lCriteriaQuery.select(lBuyorderRoot).where(
lCriteriaBuilder.and(
lCriteriaBuilder.like( lBuyorderRoot.get(Buyorder_.relation).get(Relation_.name), "Rehm%"),
lCriteriaBuilder.greaterThanOrEqualTo( lBuyorderRoot.get(Buyorder_.buydate), from),
lCriteriaBuilder.lessThanOrEqualTo( lBuyorderRoot.get(Buyorder_.buydate), upToAndIncluding)
)
);
TypedQuery<Buyorder> lQuery = lEntityManager.createQuery(lCriteriaQuery);
List<Buyorder> buyorders = lQuery.getResultList();

Querydsl:
JPAQuery lJPAQuery = new JPAQuery(lEntityManager);
QBuyorder buyorder = QBuyorder.buyorder;
List<Buyorder> buyorders = lJPAQuery.from(buyorder).where(
buyorder.relation.name.like("Rehm%")
.and( buyorder.buydate.goe(from))
.and( buyorder.buydate.loe(upToAndIncluding))
).list(buyorder);


The biggest difference is the Querydsl uses a fluent API for the where clause; where(...).and(...).and(...),
plus the field access is simpler: lBuyorderRoot.get(Buyorder_.relation).get(Relation_.name) vs buyorder.relation.name.
Glancing at the code, Querydsl seems distinctively more compact (true, the Querydsl code is written more compact, but that kinda flows from the fluent API).
Generating the meta classes in QueryDSL is a piece of cake, JPA2's are not that easy ATM.

But I'm not sure this is worth adding an additional library to the project for, with the chance that things may become incompatible in the future.
On the other hand, things that work now probably will work in the future. Only new features should be a problem and one can always fall back on the JPA API.
What I do feel is that the JPA team should have looked more at Querydsl's API, especially the property chaining. Querydsl is old enough, having started back in 2005.

Tom

PS: I didn't use "between" on purpose, so I had some more arguments in the whereclause.
Re: Querydsl [message #555755 is a reply to message #554763] Sat, 28 August 2010 05:56 Go to previous messageGo to next message
Timo Westkämper is currently offline Timo Westkämper
Messages: 4
Registered: August 2010
Junior Member
I am the maintainer of Querydsl, so my position is quite biased. The key enabler of the fluent API in Querydsl is the dynamic metamodel, which is much easier to use than the static one used in JPA 2.

See here if you are not convinced : http://source.mysema.com/forum/mvnforum/viewthread_thread,49

Querydsl has started in 2007, not 2005, and has been released to Open Source in 2008. We participated actively in the discussion when JPA 2 was specified, but the specification lead and other involved parties preferred a different approach.

And concerning the Querydsl example, it can also be expressed like this :

JPAQuery query = new JPAQuery(entityManager);
QBuyorder buyorder = QBuyorder.buyorder;
List<Buyorder> buyorders = query.from(buyorder)
  .where(
    buyorder.relation.name.like("Rehm%"),
    buyorder.buydate.goe(from),
    buyorder.buydate.loe(upToAndIncluding)
).list(buyorder);


I'ts .NET LINQ we are trying to catch up with in this area, and Querydsl comes much closer to it than JPA 2 Criteria.

I don't see much benefits in the static metamodel. What do you think?
Re: Querydsl [message #555767 is a reply to message #555755] Sat, 28 August 2010 07:13 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
> Querydsl has started in 2007, not 2005, and has been released to Open Source in 2008. We participated actively in the discussion when JPA 2 was specified, but the specification lead and other involved parties preferred a different approach.

I peeked at the little graph in sourceforge and though I saw a start in 2005. It amazes me that another approach was preferred; apparently there were arguments for that? Since JPA2 also requires the generation of metaclasses, I'm curious what these were.


> I don't see much benefits in the static metamodel. What do you think?

I'm not sure what the difference is. As said in the original email; I've just started to explorer the new query JPA2 API's and waited for them to compare it with Querydsl.

Tom
Re: Querydsl [message #555770 is a reply to message #555767] Sat, 28 August 2010 08:42 Go to previous message
Timo Westkämper is currently offline Timo Westkämper
Messages: 4
Registered: August 2010
Junior Member
> I peeked at the little graph in sourceforge and though I saw a start in 2005. It amazes me that another approach was preferred; apparently there were arguments for that? Since JPA2 also requires the generation of metaclasses, I'm curious what these were.

Here is a discussion with Gavin King : http://relation.to/10262.lace#comments

I don't really get the point with symmetry. I think the fluent approach makes much more sense than the builder-style.

> I'm not sure what the difference is. As said in the original email; I've just started to explorer the new query JPA2 API's and waited for them to compare it with Querydsl.

The Querydsl metamodel is dynamic, because you can instantiate the metamodel types and use them directly to create path and operation expressions.

In JPA 2 you can refer to metamodel fields, but you can't use the metamodel directly to express query variables etc, because it is static.

Luckily the JDO guys are smarter. They took Querydsl as the basis for their typesafe query language : http://datanucleus.blogspot.com/2010/06/jdo-typesafe-refacto rable-queries.html

But I am keen to hear some arguments in favor of the JPA 2 Criteria API. I myself don't see any.

[Updated on: Sat, 28 August 2010 14:42]

Report message to a moderator

Previous Topic:Two questions
Next Topic:Having multiple orm.xml
Goto Forum:
  


Current Time: Mon Jul 28 02:16:44 EDT 2014

Powered by FUDForum. Page generated in 0.05470 seconds