[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4965?page=c...
]
Steve Ebersole commented on HHH-4965:
-------------------------------------
Took me a little to get "back into" this code. Essentially what happens is that
we normally rely on the "type guessing" performed in the HQL translator.
However there are times when that is not specific enough; dates/times/timestamps come to
mind, where the translator resolves one type but we really want to use the type indicated
to the criteria query. I think its just a matter of this being a little over-aggressive
in terms of when to do this "namedParameterTypeRedefinition". I'll work on
this.
Implicit parameters abusively use TypeFactory.heuristicType losing
UserType and XToOneType info
-----------------------------------------------------------------------------------------------
Key: HHH-4965
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4965
Project: Hibernate Core
Issue Type: Bug
Components: entity-manager
Affects Versions: 3.5.0-CR-1
Reporter: jean-claude cote
Assignee: Steve Ebersole
Fix For: 3.5.x
Attachments: HHH-4965-unit-test.diff
Emmanuel
There seems to be a bug in the QueryImpl class in the method
extractParameterInfo()
Here's what I've done:
I create an equal predicate using a Path to House.address and a Address value.
@Entity
class House
{
@Type(type="jc.AddressUserType")
@Columns(columns={@Column(name="address")})
Address address;
In the extractParameterInfo() method there is a loop that gets the
javaType from a namedParameterTypeRedefinition.
It gets the javaType (Address.class) then since it is not null tries
to find the hibernate Type using the TypeFactory.heuristicType()
method. But given a javaType this will only work for strings, int,
double etc. What is passed in is an Address not an AddressUserType.
The huristicType actually returns an hibernate SerializableType and
resets the descriptor which was correct in the first place.
I've fix this for myself my just commenting out the call to
resetExpectedType but there must be a good reason why this call is
made there correct?
Thanks
Jean-Claude
@SuppressWarnings({ "unchecked", "RedundantCast" })
private void extractParameterInfo(Map<String,Class>
namedParameterTypeRedefinition) {
if ( ! AbstractQueryImpl.class.isInstance( query ) ) {
throw new IllegalStateException( "Unknown query type for
parameter
extraction" );
}
HashSet<Parameter<?>> parameters = new
HashSet<Parameter<?>>();
AbstractQueryImpl queryImpl = AbstractQueryImpl.class.cast( query );
// extract named params
for ( String name : (Set<String>)
queryImpl.getParameterMetadata().getNamedParameterNames() ) {
final NamedParameterDescriptor descriptor =
queryImpl.getParameterMetadata().getNamedParameterDescriptor( name );
Class javaType = namedParameterTypeRedefinition.get( name );
if ( javaType != null ) {
descriptor.resetExpectedType(
TypeFactory.heuristicType(
javaType.getName() )
);
}
else if ( descriptor.getExpectedType() != null ) {
javaType =
descriptor.getExpectedType().getReturnedClass();
}
final ParameterImpl parameter = new ParameterImpl( name, javaType
);
parameters.add( parameter );
if ( descriptor.isJpaStyle() ) {
if ( jpaPositionalIndices == null ) {
jpaPositionalIndices = new
HashSet<Integer>();
}
jpaPositionalIndices.add( Integer.valueOf( name ) );
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira