In the post today we will see about the new version of the framework named EasyCriteria. At the end of this post we will see what is to come here in the blog. Unfortunately the JPA criteria has a huge problem that is its verbosity. Why not make easier? Thinking like this that EasyCriteria framework were born and now it is on version 2.0. To do a simple JPQL with the JPA Criteria the following code would be needed:
CriteriaQuery<Person> criteriaQuery = criteriaBuilder.createQuery(Person.class); Root<Person> root = criteriaQuery.from(Person.class); criteriaQuery.select(root); TypedQuery<Person> query = entityManager.createQuery(criteriaQuery); query.getResultList();
Notice all the code needed to do the query: select p from Person p. Check below how easy it is to do the same Criteria with EasyCriteria:
EasyCriteria<Person> easyCriteria = EasyCriteriaFactory.createQuery(entityManager, Person.class); easyCriteria.getResultList();
The difference between version 1.0 and the 2.0 version is in the reduction of methods into generic methods. To compare methods with =, >=, <, <=, and other methods just use the API like below:
easyCriteria.andGreaterThan('hairSize', 10.4f); // >
easyCriteria.andGreaterOrEqualTo('height', 11.00d); // >=
easyCriteria.andLessThan('totalBooksOwned', 30L); // <
easyCriteria.andLessOrEqualTo('firstJobDate', firstJobDate); // <=
easyCriteria.andJoinEquals('dogs', 'age', 15); // =
easyCriteria.andJoinStringIn('dogs', 'name', names); // value in (x, i, z, ...)
easyCriteria.andJoinStringLike('dogs', 'name', '%y');One of the ideals of the EasyCriteria framework is to expose the lower number possible of API to the user. Thinking like this, EasyCriteria added the “OR” condition to its API without new classes. Take a look below to see how to do queries with OR:
select s from Song s where s.id = 1 or s.length = 40 or s.artist = 'Group 1 Crew'
easyCriteria.orEquals('id', 1).orEquals('length', 40).orEquals('artist', 'Group 1 Crew');Another type of OR could be done:
select s from Song s where (s.id = 1) or (s.id = 2) or (s.length = 40) or (s.artist = 'Group 1 Crew')
easyCriteria.orEquals('id', 1, 2).orEquals('length', 40).orEquals('artist', 'Group 1 Crew');And it is possible to do complexes queries cases like:
select s from Song s where (s.totalDownloads = 20 or s.weight = 10.00) and (s.price = 20.00 or s.type = :type)
easyCriteria.orEquals(1, 'totalDownloads', 20L).orEquals(1, 'weight', 10.00f).orEquals(2, 'price', 20.00d).orEquals(2, 'type', SongType.PRAISE);
The idea of index were added to the API to be used with a group of OR. The first OR group is composed of “totalDownloads” and “weight”, the second group has “price” and “type” as elements. As default index the value 1 is always used. The criteria above could be written as:
easyCriteria.orEquals('totalDownloads', 20L).orEquals('weight', 10.00f).orEquals(2, 'price', 20.00d).orEquals(2, 'type', SongType.PRAISE);It is possible create a query to do the inverse of the query above, AND separated by OR:
select s from Song s where (s.id = 1 and s.name = 'Sing Out') or (s.id = 2 and s.name = 'Alive')
easyCriteria.addAndSeparatedByOr(1, 'id', 1).addAndSeparatedByOr(1, 'name', 'Sing Out').addAndSeparatedByOr(2, 'id', 2).addAndSeparatedByOr(2, 'name', 'Alive');
That is all for today, I hope you like the new version. It will take a long time to consider this framework complete. Helping with the OR functionality I could count with João Neves (http://about.me/joaonevesfilho) and Sasaki (http://curriculum.rodrigosasaki.com/). Here it is possible to see the framework official page: http://easycriteria.uaihebert.com/. And the best, it is open source (http://code.google.com/p/easy-criteria/).
Other fact about the framework is that it is 100% covered with tests using Cobertura. EasyCriteria was tested with OpenJPA, EclipseLink and Hibernate. Now it is time to ask for your help. It was found bugs in the tested implementations; it would be wonderful if you spare 5 minutes of your time voting in the bugs. With your vote the bug could be corrected faster.
- EclipseLink: https://bugs.eclipse.org/bugs/show_bug.cgi?id=386354
- OpenJPA: https://issues.apache.org/jira/browse/OPENJPA-2333
- Hibernate: https://hibernate.onjira.com/browse/HHH-7985
What is to come in the blog? It took so much time for me to write this post because I am finishing my first book. If God’s will, the book will be released in March. In this pause of new posts here, I have studied a lot of Maven and I want my next post to be about a mini book about a basic Maven and full web applications. Yes, I said “applications” in plural.
Reference: EasyCriteria 2.0 – JPA Criteria should be easy from our JCG partner Hebert Coelho at the uaiHebert blog.
Herbet congratulations for the initiative.
Thanks! =D
The “criteriaQuery.select(root);” line in your example is not required.
Then, why are you promoting string-based API’s? One of the best feature of the criteria API is it’s type safety, provided by the meta-model. It’s not making writing queries easier, although not as verbose as what you’d suggest. It’s helping making them object-oriented and type-safe.
The review process for jpa’s next iteration ended a few weeks ago, why didn’t you try to make suggestions there instead of a new reinventing-the-wheel framework (missing the point, btw)?
I will post here the same answer I gave you in my blog: Hello Yannick, how are you? Indeed the select is required when the where is used, but I did not see a criteria without an where clause. One thing to have in mind is that metamodel is good, but is hard to those that are starting with JPA Criteria to understand this hard concept. I am not reinventing nothing because I have not found a framework like mine, using only string. [= But for next versions I want to add the metamodel capability to support both models of… Read more »
Hello Hébert, CriteriaQuery can also be used with strings (although I wouldn’t throw away the type-safe goodness). It’s (somewhat) more verbose, but with reasons. Your API makes some simple things simple and difficult things impossible. Typing has been left out. CriteriaQuery isn’t that difficult, really. I don’t think oversimplification helps beginners. The difference between something like this and CriteriaQuery is that the latter has been thought out by multiple actors, having to agree (JSR). The process is quite open, and you had the chance to tell your point of view in the public review. In that sense, you reinvented the… Read more »
Hello Yannick, That is your opinion and I do respect that, although is not the feedback that I am receiving from the users of the framework. I know several juniors developers that did not use JPA Criteria because its complexity. The same way you think it is easy, I with several other developers think that the API is hard to learn and use. I believe that when I create this framework I had to have a good knowledge in JPA. I am not splinting it, I am making easier to use it. Sorry if I did not google searching for… Read more »
Hello Hébert,
My point is that your complaint, “JPA Criteria should be easy”, should be addressed by telling the JPA expert committee. They did ask for community feedback on the next version. That’s the JCP/JSR process, you can check it or ignore it as you wish but this process is a fact, not my sole opinion. Please don’t take it personnally, but I’d really suggest to beginners to use the real thing – this “framework” is full of inaccurate shortcuts. Sorry again for the negative feedback, I just think that beginners should hear them too.
Hello Yannick, I am not the kind of person that complains/criticize about something without a solution. That is why I do not want and will not talk with JPA team yet. When EasyCriteria is ready I will talk to the JPA about this verbosity problem and show a solution. If they want to use my framework, great. If they do not want to use that is fine, a lot of people will want to use it. I will be available to help JPA team if they want to. You do not need to apologize for your negative feedback, it does… Read more »