I am trying to to an eager join fetch of a ManyToOne association using
session.createQuery("from OrigemVO obj").list(),
but that always executes a select fetch type.

usin session.createCriteria(OrigemVO.class).list() works, but I think that is an Hibernate bug.
Can anyone help me ? I can´t use Criteria in my code because it is already in production.


Hibernate version: 3.2.0 GA

Mapping documents:
@Entity
@Table(name="ORIGENS", schema="JCOMPANY")
public class OrigemVO {

@Id
@Column (name = "CD_ORIGEM", nullable=false)
private Long id;


@SuppressWarnings("unchecked")
@ManyToOne (targetEntity = JurisdicaoVO.class, fetch = FetchType.EAGER)
@JoinColumn (name = "CD_JURISDICAO", nullable=false)
@Fetch(FetchMode.JOIN)
private Jurisdicao jurisdicao;

... Getters and setters ommitted ...
}

@Entity
@Table(name="JURISDICAO", schema="JCOMPANY")
public class JurisdicaoVO {


@Id
@Column (name = "CD_JURISDICAO", nullable=false)
private Long id;


@Column (name = "DS_JURISDICAO", nullable=false, length=40)
private String dsJurisdicao;
}

Code between sessionFactory.openSession() and session.close():

session.createQuery("from OrigemVO").list();

Name and version of the database you are using:
Oracle 10g

The generated SQL (show_sql=true):
select
origemvo0_.CD_ORIGEM as CD1_1_,
origemvo0_.VERSAO as VERSAO1_,
origemvo0_.DT_ALTERACAO as DT3_1_,
origemvo0_.NM_USUARIO as NM4_1_,
origemvo0_.DS_ORIGEM as DS5_1_,
origemvo0_.SG_UF as SG6_1_,
origemvo0_.CD_JURISDICAO as CD9_1_,
origemvo0_.COD_TST as COD7_1_,
origemvo0_.COD_IBGE as COD8_1_
from
JCOMPANY.ORIGENS origemvo0_


select
jurisdicao0_.CD_JURISDICAO as CD1_0_0_,
jurisdicao0_.DS_JURISDICAO as DS2_0_0_
from
JCOMPANY.JURISDICAO jurisdicao0_
where
jurisdicao0_.CD_JURISDICAO=?


Should Be:

select
this_.CD_ORIGEM as CD1_1_1_,
this_.VERSAO as VERSAO1_1_,
this_.DT_ALTERACAO as DT3_1_1_,
this_.NM_USUARIO as NM4_1_1_,
this_.DS_ORIGEM as DS5_1_1_,
this_.SG_UF as SG6_1_1_,
this_.CD_JURISDICAO as CD9_1_1_,
this_.COD_TST as COD7_1_1_,
this_.COD_IBGE as COD8_1_1_,
jurisdicao2_.CD_JURISDICAO as CD1_0_0_,
jurisdicao2_.DS_JURISDICAO as DS2_0_0_
from
JCOMPANY.ORIGENS this_
inner join
JCOMPANY.JURISDICAO jurisdicao2_
on this_.CD_JURISDICAO=jurisdicao2_.CD_JURISDICAO

HQL ignores completely the fetching strategy: it's a choice. The Criteria overrides the strategy. That explains why the behavior differs in your example.

When you build a HQL query be sure to define what you expect to load (using the HQL fetch keyword)

Emmanuel,

That does not seem right. I mean, the HQL should assume the default fetching strategy instead of explicitly refer each association fetch type. This is already set on the entity itself. This way, a developer may (and will) easily forget to put the fetch type for each association (imagine having more than just one), it may not be possible to write a HQL that should execute as performatic as it was defined. IMHO, I suggest that the fetching strategy chosen for the association be used, being overruled by the proper HQL statement.

What do you think ?

OTOH the user anticipates in a better way the SQL generated and the associated perfs. And a HQL non-fetch keyword would have been very odd.
This has been our choice since the earliest versions, people are used to it.

But what causes the behavior in createCriteria to be different ? BPTW, I guess that it should have the same behavior, isn't it ?

BPTW = Being Put this way

It is more natural to express the negative overriding with a criteria API :)

Hum... I don't know why, but that does not seem to buy.
I wonder if Toplink has the same behaviour (not tested yet).
Does the JPA specification state anything about it ?

The spec is pretty clear.
FetchType defines the lazyness of the field, not the fetching strategy (I know the name sucks).
Using a SQL JOIN is guaranteed when you use the JPA-QL fetch keyword.