[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4965?page=c...
]
Emmanuel Bernard commented on HHH-4965:
---------------------------------------
Detailed analysis.
LiteralExpression#render alter the renderer for numerics (I imagine to comply with JPA 2
rules on it).
But for non numerics, it register an ImplicitParameterBinding that is added by ricochet to
QueryImpl#namedParameterTypeRedefinition.
We then call TypeFactory.heuristic on implicit parameters whose Type is well defined.
I am not sure if this is expected or why. Here are two "working" patches (with
the current test suite):
- remove the first if branch of QueryImpl#extractParameterInfo inside the for loop
- make sure LiteralExpression#render() register an ImplicitParameterBinding that returns
null on getJavaType()
Steve will know more about the context and chose the best approach.
To test, try the test dedicated to HHH-5108 (@FailureExpected).
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: Emmanuel Bernard
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