Creating and running queries in Java

Generator QR Code in Java Creating and running queries

itemCursor.scroll(-3); itemCursor.close();

This code doesn t make much sense; it displays the most interesting methods on the ScrollableResults interface. You can set the cursor to the first and last Item object in the result, or get the Item the cursor is currently pointing to with get(). You can go to a particular Item by jumping to a position with setRowNumber() or scroll backward and forward with next() and previous(). Another option is scrolling forward and backward by an offset, with scroll(). Hibernate Criteria queries can also be executed with scrolling instead of list(); the returned ScrollableResults cursor works the same. Note that you absolutely must close the cursor when you re done working with it, before you end the database transaction. Here is a Criteria example that shows the opening of a cursor:

ScrollableResults itemCursor = session.createCriteria(Item.class) .scroll(ScrollMode.FORWARD_ONLY); ... // Scroll only forward itemCursor.close()

The ScrollMode constants of the Hibernate API are equivalent to the constants in plain JDBC. In this case, the constant ensures that your cursor can only move forward. This may be required as a precaution; some JDBC drivers don t support scrolling backward. Other available modes are ScrollMode.SCROLL_INSENSITIVE and ScrollMode.SCROLL_SENSITIVE. An insensitive cursor won t expose you to modified data while the cursor is open (effectively guaranteeing that no dirty reads, unrepeatable reads, or phantom reads can slip into your resultset). On the other hand, a sensitive cursor exposes newly committed data and committed modifications to you while you work on your resultset. Note that the Hibernate persistence context cache still provides repeatable read for entity instances, so only modified scalar values you project in the resultset can be affected by this setting. So far, the code examples we ve shown all embed query string literals in Java code. This isn t unreasonable for simple queries, but once you begin considering complex queries that must be split over multiple lines, this gets a bit unwieldy.

We don t like to see HQL or JPA QL string literals scattered all over the Java code, unless really necessary. Hibernate lets you externalize query strings to the mapping metadata, a technique that is called named queries. This lets you store all que-

ries related to a particular persistent class (or a set of classes) encapsulated with the other metadata of that class in an XML mapping file. Or, if you use annotations, you can create named queries as metadata of a particular entity class or put them into an XML deployment descriptor. The name of the query is used to call it from application code. Calling a named query In Hibernate, the getNamedQuery() method obtains a Query instance for a named query:

session.getNamedQuery("findItemsByDescription") .setString("desc", description);

In this example, you call the named query findItemsByDescription and bind a string argument to the named parameter desc. Java Persistence also supports named queries:

em.createNamedQuery("findItemsByDescription") .setParameter("desc", description);

Named queries are global that is, the name of a query is considered to be a unique identifier for a particular SessionFactory or persistence unit. How and where they re defined, in XML mapping files or annotations, is no concern of your application code. Even the query language doesn t matter. Defining a named query in XML metadata You can place a named query inside any <hibernate-mapping> element in your XML metadata. In larger applications, we recommend isolating and separating all named queries into their own file. Or, you may want some queries to be defined in the same XML mapping file as a particular class. The <query> defines a named HQL or JPA QL query:

<query name="findItemsByDescription"><![CDATA[ from Item item where item.description like :desc ]]></query>

You should wrap the query text into a CDATA instruction so the XML parser doesn t get confused by any characters in your query string that may accidentally be considered XML (such as the less than operator). If you place a named query definition inside a <class> element, instead of the root, it s prefixed with the name of the entity class; for example, findItemsByDescription is then callable as auction.model.Item.findItemsByDescription. Otherwise, you need to make sure the name of the query is globally unique.