Here are my constraints:
1. I cannot change the database schema (I wish I could)
2. I have the following class hiearchy
Item is a class
Item.sku is a property of Item

Staple is a joined-subclass of Item
Staple.description is a property of Staple

Pack is a joined-subclass of Item
Pack.description is a property of Pack

Notice that because of the legacy schema ($#%!$), the description property is duplicated in each of the subclasses ($#%#$). Good-design would have moved this shared column to the baseclass-table, but I am stuck with this schema.

I want to retrieve all items that meet the following criteria:
staple.description LIKE ?
OR pack.description LIKE ?

I know I can get what I want in two queries

SOLUTION 1)
HQL 1: from Staple as staple where staple.description LIKE ?
HQL 2: from Pack as pack where pack.description LIKE ?

But then I lose all the group by , ordering techniques if I plan on displaying the resulting <Item>Collection in a page. I'd have to do all this in my code - ick.

SOLUTION 2) -this does not exist
A Hibernate union could support this, but I know Hibernate unions are not supported (outside of a direct SQL call).

SOLUTION 3) Is there some way of mapping an "abstract" property of the base-class (Item) to a column in a declared subclass? E.g. is there a way that I can map Item.description to STAPLE.DESCRIPTION if it is a Staple, and to PACK.DESCRIPTION if it is a Pack?
If this is the case then my HQL query becomes easy:

HQL: from Item as item where item.description LIKE ?

SOLUTION 4) None of the above - something else?

SOLUTION 5) I lose. Give up on Hibernate.

The 3rd one should work on Hibernate 2.2 (alpha version however).
Check the dev mailing list

Ugh. Actually it would not work even in 2.2, since the "typecast" stuff only supports distinct property names in the entire hierarchy.

You will need to define different properties on each subclass.

I think I will wait for Hibernate 2.2 (non-Alpha) for this.
Until then, I think I will have to stick with SOLUTION 1) and add my own in-memory sorters to SORT or GROUP on the in-memory collection.
Would I rather have the DB do it?
Yes... but in the interest of saving development time and getting a solution to work, I can live with this for now.

Thanks for the quick response!