HQL forces programmers to drop into an SQL-like syntax for certain operations. So it would seem that Hibernate developers still need to know SQL. Fortunately, Hibernate offers a set of APIs that map the SQL functionality to objects. This allows programmers to use an entirely object-oriented approach without falling back on a relational methodology. Keep reading to find out more.
Hibernate: Criteria Queries in Depth - The Core Classes of Criteria Queries (Page 2 of 4 )
Each class of the Criteria Query API represents an aspect of the relational approach. There are five core APIs that are commonly used. They are:
1. Criteria
2. Criterion
3. Restrictions
4. Projection
5. Order
The Criteria class provides the gateway to working with criteria APIs. It is an interface that provides a simplified API for retrieving objects containing or composed of Criterion objects. In a situation where the restrictions query is composed of a variable number of fields, this approach is very useful. To get a reference to the Criteria class, use the createCriteria() method of the Session class. This method takes the name of the ORM class on which the query has to be executed. In essence the Session acts as a factory for the Criteria class. In statement form it would be:
The above statement returns a reference to Criteria for the Order ORM class.
Looking at the second core API, in the relational approach, conditions placed on retrieving data are known as criterion. The Criterion class is the object-oriented representation of the relational criterion. It can be used as restrictions on the criteria query. In other words, Criterion is the object-oriented representation of the "where" clause of a SQL query. The conditions to be applied (also known as restrictions) can be provided by the Restrictions class. In code this would be:
From the above example it is clear that the Criterion is the "where" clause, which, when added to the Criteria object, provides a complete query with restrictions.Here the built-in Restriction type eq() (for testing equality) is being used.
The Restriction API provides the built-in types for Criterion. Essentially, the Restriction class is a factory to the Criterion class. All of its methods are static. In Hibernate 2.x, the Expression class provided the services that are now provided by the Restriction class. The Restriction class provides almost all the required restrictions such as equals (eq()), logical and (and()), like (like()) and so on. Here I have used the term ‘almost’ because some of the restrictions dealing with Grouping are provided by the Projection class.
The Projection class is an object-oriented representation of query resultset projection in a Criteria query. In simpler terms, projection refers to the fields mentioned in the select clause of a query. The same can be achieved by using the Projection class in a Criteria query. The Projection class acts as a factory for the Projection class. Projection can be added by using the addProjection() method of the ProjectionList class. The addProjection() method of the Criteria class in turn returns a Criterion object. In code this would be:
List orders = session.createCriteria(Order.class) .setProjection( Projections.projectionList() .add( Projections.rowCount() ) ).list();
The Order class represents the "order by" clause of SQL. By using the asc() and desc() methods of this class, order can be imposed upon the Criteria resultselt.
Those are the major core classes of Hibernate. Though this clears the air about participating classes, how they are really used is still a question. That is what I am going to discuss in next section.