This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
i'm currently studying Pro JPA 2 book and by now, I'm on the Criteria API chapter ... And OMG this way of writing query is just terribly complicated and ... definitively unreadable !!
But we have to study it (a shame because I perfectly know that I will never use such a thing ! I can't even imagine someone who discover that kind of query in a real world project with thousand of queries)
Still we have to know all of it ...
I try, when reading, to write down every methods and inheritance stuffs but I can't make it clear
Does anyone know where to find a class diagram with all important Interfaces and methods ? a kind of sum up diagram ?
And I am curious about this. Does anyone ever met the use of Criteria API on a real project ? What's the gain ?
When I started using the JPA Criteria API, I didn't understand why it was so complicated compared to the Hibernate one. For a simple query, it's a lot of work. However, when you end up having to create large queries that differ heavily, it ends up being quite easy to use. Especially reusing and joining parts of queries can be extremely simple. When you have to do complicated stuff using it, you really notice they put a lot of thought in it. For a tutorial, check out http://www.ibm.com/developerworks/java/library/j-typesafejpa/ and http://docs.oracle.com/javaee/6/tutorial/doc/gjitv.html . They should make it a little easier to understand.
I don't like it either. It assumes that the developer is going to spend their time writing specific searches on specific tables and columns. I like to think of persistence as a done deal, no need to solve it again and again for new projects, tables even. The reliance on generated code is also a nuisance, changes in the model (yes they shouldn't be often but still) become more painful to deal with.
For most projects I use a generic search method (uses the criteria API with some reflection) that can search on any column of any type on any table. It was written and tested once, it works fine most of the time, when it doesn't work I then fall back to specific queries.
It's obviously not type safe but I cover all required search scenarios in the test cases anyway so the main type safe argument falls away. I consider that the savings I get from not having to repeat similarly structured queries for different entity names is worth it in case.
As with any API, the details of the project decide which approach should be used.
I tried to refrain from posting a reply on this topic but what the heck!
I agree with OP. On three different projects that I have worked on in the past 6 years, the following is what I have seen happening:
The project started idealistically with Hibernate(or later, JPA) with queries written in HQL/JPQL and also using Criteria API. As is usually the case in Agile methodology, no sooner did the project went into UAT, change requests started coming. Also, as is usually the case, contract developers kept rolling on/off the project. By the end on an year or so, most of the code that was written using criteria queries was replaced with pure sql queries. Why? Because the developer who got the task of modifying the code needed quite a bit of time to figure out what was the code doing. Plugging in an SQL query was the quickest way to get the job done.
Wait, that's not all. Most of the time I have seen that the you need to "fine tune" the query to get the data you want. So you grab the DB Artisan/TOAD window and work out the SQL. Now, writing Criteria query that spits out the same SQL is either impossible or frustratingly time consuming.
After all, most people have a limited time allocated for work. In their mind, they are saying, "f*ck this sh*t, I am putting the same SQL in the code". So they take the faster approach. They get rid of the code that requires time to comprehend, and patch in new code with SQL that just short circuits everything.
That's still not all! I am yet to see a project that has absolutely no SQL. No matter how hard you try to avoid SQL, you will always get something for which you need to write SQL. So in every project, there will always be some kind of framework/pattern that is used to work with SQLs. There will be a "queries.xml" lying around somewhere. So you just grab that file, plant your new sql in it and see Criteria query off in your rear view mirror.
I have no intention to comment on the purity or goodness of Criteria API. I am sure it is a great thing. But it is just not practical from a TCO point of view. At least that's what I have learnt and I am never going to use it on my projects.
Enthuware Software Support
Joined: Sep 23, 2000
Oh, and one more thing. IMHO, no one is going to hold it against you in an interview if you do not know criteria API. But if you can't write SQLs, you can pretty much kiss a Java developer position goodbye.
But if you can't write SQLs, you can pretty much kiss a Java developer position goodbye.
I would not completely agree with this statement. True, an experienced server-side developer working in Java will over time need to learn some SQL but there are projects where the database and data access tier are taken care of by another team. You may also be asked to work soley on the presentation tier and have zero involvement with the database. Also remember that there are an increasing number of no SQL databases emerging.
Paul Anilprem wrote:I tried to refrain from posting a reply on this topic but what the heck!
I'm glad you replied though :-)
I agree with you, Criteria is too different from anything else to simply get a grasp on if you're not used to it (that's why we're learning for this exam, right? :-p).
But what I love about it, is that it's way easier to mock and test than those pesky sql strings. How many times I've seen change be made in the database (for example change the name of a column), only to discover an sql query to fall over in production because there's just no way to test your queries. So I agree with you that it's hard to learn and read, but if all kinds of developers start to delete Criteria code in preference of sql or jpql, that's just bad, hire someone else (someone with a JPA Certificate :-))