you can easily load scalar values with the criteria API, you do not need HQL for this.

Example:
You have a Company with an one-2-one relation to an Address.
You just want to query id and name of the Company and the countryCode of its related Address.

myCompanyCriteria.createAlias(”address”, “joinedAddress”);

myCompanyCriteria.setProjection(
Projections.projectionList()
.add( Projections.id(), “id” )
.add( Projections.property(”name”), “name” )
.add( Projections.property(”joinedAddress.countryCode”), “countryCode” )
);

myCompanyCriteria.setResultTransformer( new AliasToBeanResultTransformer(CompanyVO.class) );

The Class CompanyVO just needs setter for id, name and countryCode.

Regards

>But what if I only need a list of names and ids? I don’t need placeholder
>objects taking up space in my JVM if they’re never used.

So how can one achieve such a query which does not pull in all the properties?

Thanks,
Dan

Eg. you have a Brokerage that contains many Brokers, when you fetch a list of Brokerages, you do not want the child relationship brokers to be eagerly fetched - it should be allowed to remain in the normal lazy mode. However, when you’re fetching a specific Brokerage for display, in a context that wants to also display a table of the Brokers within the Brokerage, then you want the Brokers to be fetched eagerly (perhaps with a “from parent as p left join fetch p.dependentObject” DAO method) as part of the Brokerage fetch to avoid an N+1 fetch scenario.

(If Brokers and Brokerages are not your bag, you can substitute Brokerage with Order, and Broker with OrderLine for the same effect)

Providing the DAO layer is the primary method for fetching objects (and you never pollute the service/UI layers with hibernate manipulations of the persisted object graph) then it is quite reasonable to have transaction specific logic - it’s still only in one place, just not enforced at a POJO domain object level, where there is no knowledge of the transactional context of an operation.

I find I still end up using HQL for most of my DAOs, however, because HQL can return scaler results which are far more performant than fully-hydrated objects. Sometimes I don’t need a whole domain object–I just want a couple of properties. For instance: let’s say I have a Customer class that has dozens of simple properties (id, name, account number, etc.), as well as a bunch of associated collections (Addresses, Bank Accounts, Transactions, etc.). If I do a criteria query on the Customer.class, I’ll get a bunch of Customer objects back with all the simple (non-lazy) properties, and PersistentCollection placeholders for my (lazy-loaded) collections.

But what if I only need a list of names and ids? I don’t need placeholder objects taking up space in my JVM if they’re never used. A good example of this is drop-down auto-complete forms: you type something in, a list of partially matched Customers comes back. You’re not interested in the Customer’s addresses, or their lastModified date, or any of that stuff. You really just want an array of strings.

> But that knowledge is already represented in your mapping file, so this
> is repeating that knowledge in many places

The Hibernate docs actually recommend *against* specifying fetching strategies in the mappings. From the docs (19.1.2. - Tuning fetch strategies): “Usually, we don’t use the mapping document to customize fetching. Instead, we keep the default behavior, and override it for a particular transaction…”

The main problem is when going back and running the same query that could have been expressed as an object relationship. The natural object relationships are where hibernate shines. HQL should be reserved for very special situations.