Issue with queries using the Query class and a named parameter.

When using the Query class with a named parameter, all joined sub classes are joined in the generated sql statement, example below. But if a session.find() is used instead then the generated sql statement is correct and only joines the super class with the sub class. I'm able create, save, and select objects so the meta data mapping is correct. The issue is the difference between the two query methods.

Here is an excerpt of the metadata that is relevant.
All that is irrelevant is removed for clearity.
The choosen excerpt is randomly picked from all queries that showed the same effect.

- <hibernate-mapping default-cascade="none" default-access="property" auto-import="true">
- <class name="nl.tresparc.model.TDModelObject" dynamic-update="false" dynamic-insert="false" mutable="true" polymorphism="implicit" batch-size="1" select-before-update="false" optimistic-lock="version">
- <id name="id" column="id" type="long" access="field" unsaved-value="null">
<generator class="native" />
</id>
<version name="version" type="timestamp" column="version" access="field" unsaved-value="undefined" />
- <joined-subclass name="nl.tresparc.model.TDComplexType" dynamic-update="false" dynamic-insert="false">
<key column="id" />
<property name="internalName" type="java.lang.String" update="true" insert="true" access="field" column="internal_name" not-null="false" unique="false" />
</joined-subclass>

Now for the query used.
session.find("select t from TDComplexType as t where t.internalName = 'ITEM'");

Generates the expected sql statement with only a single join between the super and sub class (I removed the properties from the select) :
Hibernate: select tdcomplext0_.id as id,
from TDComplexType tdcomplext0_
inner join TDModelObject tdcomplext0__1_ on tdcomplext0_.id=tdcomplext0__1_.id
where (tdcomplext0_.internal_name='ITEM' )


On the other hand this:
Query query = session.createQuery("select t from TDComplexType as t where t.internalName = :internalName");
query.setString("internalName", "ITEM");

Generates the unexpected sql statements joining all sub classes of TDModelObject:

select tdcomplext0_.id as x0_0_
from TDComplexType tdcomplext0_
inner join TDModelObject tdcomplext0__1_ on tdcomplext0_.id=tdcomplext0__1_.id where (tdcomplext0_.internal_name=? )

select tdcomplext0_.id as id12_,
tdcomplext0_.internal_name as internal2_4_12_,
tdcomplext0_.name as name4_12_,
tdcomplext0_.view as view4_12_,
tdcomplext0_.icon as icon4_12_,
tdcomplext0_.base_type_id as base_typ6_4_12_,
tdcomplext0_.item_classname as item_cla7_4_12_,
tdcomplext0_.namespace as namespace4_12_,
tdcomplext0_.cardinality as cardinal9_4_12_,
tdcomplext0__1_.version as version1_12_,
tdcomplext1_.id as id0_,
tdcomplext1_.internal_name as internal2_4_0_,
tdcomplext1_.name as name4_0_,
tdcomplext1_.view as view4_0_,
tdcomplext1_.icon as icon4_0_,
tdcomplext1_.base_type_id as base_typ6_4_0_,
tdcomplext1_.item_classname as item_cla7_4_0_,
tdcomplext1_.namespace as namespace4_0_,
tdcomplext1_.cardinality as cardinal9_4_0_,
tdcomplext1__1_.version as version1_0_,
tdacl2_.id as id1_,
tdacl2_.version as version1_,
tdacl2_.reference_count as referenc3_1_,
tdacl2_.author as author1_,
tddomain3_.id as id2_,
case when tddomain3__4_.id is not null then 1
when tddomain3__5_.id is not null then 2
when tddomain3__3_.id is not null then 3
when tddomain3__6_.id is not null then 4
when tddomain3_.id is not null then 0 end as clazz_2_,
tddomain3_.domain_id as domain_id31_2_,
tddomain3__1_.owner as owner5_2_,
tddomain3__1_.parent_id as parent_id5_2_,
tddomain3__1_.valueAsString as valueAsS4_5_2_,
tddomain3__1_.creation_date as creation5_5_2_,
tddomain3__1_.type_path as type_path5_2_,
tddomain3__2_.version as version1_2_,
........

And so on for every sub class of TDModelObject, a total of 184 lines.

So my question is for which I could not find the answer in de the documents, forums or Google, is this expected behaviour? I could not think of any argument why the generated sql should be any different. Should the two query methods generate different sql statements? My guess is no and this is a bug.

Thanks for any advice on this subject.

Eduard

You are mistaken.