Implementing dynamic paged queries - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 434

Kodo JDO executes a SQL SELECT statement that retrieves only the columns corre-
sponding to the fields specified by the query's select clause and returns a collec-
tion of OrderSummaryDTO objects. For each row in the result set, Kodo instantiates
an OrderSummaryDTO using its default constructor and initializes it by calling set-
ters, including setOrderId() , setDeliveryTime() , and setEmail() .
If you do not need the persistent objects, then JDO projection queries are a
useful way to retrieve only the required fields without going to the trouble of
defining fetch groups.

Using Hibernate projection queries
Hibernate projection queries, like JDO projection queries, return DTO s rather
than persistent objects and can be used to load a subset of an object's properties.
Here is an example of a criteria query that returns just the ID and delivery-
Address.street1 property of the orders:

Criteria x = session.createCriteria(Order.class);
x.setProjection(Projections.projectionList()
.add(Property.forName("id"))
.add(Property.forName("deliveryAddress.street1")));
List result = x.list();
Object[] result = x.get(0);
Hibernate executes a query that retrieves only the columns corresponding to the
specified properties. Each element of the result list is an Object[] containing two
elements. Criteria queries that use projections are sometimes useful, but one
apparent limitation of criteria projection queries is that they cannot return the
property of a related object, such as the name of an order's restaurant. Another
limitation of projection queries is that each item in the projection list must map
to a single column. This means that you cannot easily retrieve an embedded value
object, such as an order's delivery address. Consequently, if you need to retrieve
the properties of related objects or embedded value objects, then you have to use
a regular criteria query.

11.3.4 Working with a denormalized schema

A common technique for improving performance is to denormalize the schema,
which reduces the number of joins that a SQL SELECT statement must use. In
order for the denormalized columns to be accessible to an application that uses a
persistence framework, they must be mapped to fields or properties in the object
model. For example, if we replicated the restaurant name by adding a