Hibernate version: 1.0.1

While a query such as



fails with the (not too surprising) exception



the simpler query



actually works fine. If reserved HQL keywords like ORDER and GROUP can be used as aliases in the FROM clause, why can't they be used in a JOIN clause?

I may be wrong but Is OrderStatus a member of Order ?

If so then I think the query should be like
SELECT Order.Date,
Order.PoNumber,
Order.OrderStatus.Description
FROM Order AS Order
LEFT JOIN FETCH Order.OrderStatus AS OrderStatus

You are using 'JOIN LEFT JOIN'.I think You should use 'LEFT JOIN FETCH'

Sorry, the "JOIN LEFT JOIN" was a typo.

Actually, while your form of the query would work as well, we need the query in the form originally shown (at least until we write a smarter HQL parser), because then we can easily parse the HQL and execute a modified statement to get the underlying entities. As a general policy, we want every query to have entities returned, not raw scalar values.

As long as our queries are in the form

SELECT A.Foo, B.Bar, C.Ack, D.Ugh, ...
FROM Ablah AS A
JOIN x1.y1 AS B
JOIN x2.y2 AS C
JOIN x3.y3 AS D
...

i.e. as long as nothing in the select list or joins goes deeper as in "SELECT A.B.Bar" or "JOIN x1.y1.z1", then we can easily parse the HQL to determine the datatypes of the selected properties, and instead issue the HQL statement without the SELECT clause. The raw query results (an object array of entities A, B, C, D ...) are then packaged into a nice "entity view row" class, where the entities are available as a dictionary keyed by their aliases in the query, and each selected property is exposed with the correct datatype, with property names A_Foo, B_Bar, C_Ack, D_Ugh ... The "entity view row" class is generated by a utility we created similar to NHibernate Query Analyzer, which we will eventually make into a Visual Studio plug-in. For cases where the query is dynamic (i.e. can't be specified at compile-time), we generate, compile and load the "row" class at runtime.

This way, when creating a UI, the developer specifies what properties they want displayed in their UI in the HQL statement, and they get back a nice set of "entity view row" objects with the properties they want to bind to, flattened to one level for easy databinding, and the underlying entities so that the user can do stuff like drill down or invoke some operation on a displayed property's underlying entity.