Querydsl [message #554763] |
Tue, 24 August 2010 11:09 |
Tom Eugelink Messages: 817 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 09:56 |
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 #555770 is a reply to message #555767] |
Sat, 28 August 2010 12:42 |
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 18:42] Report message to a moderator
|
|
|
Powered by
FUDForum. Page generated in 0.03483 seconds