]
Christian Wasel commented on HHH-3062:
--------------------------------------
I also had this error. I analyzed the code and found out the following:
The error appeares when using a HQL query with a JOIN FETCH or LEFT JOIN FETCH and the
joined entity is mapped with @OneToMany and has an embedded id.
My @OneToOne mappings work fine using FETCH with a simple id and also an embedded id.
Also @OneToMany mappings work fine using FETCH when I have just a simple id.
I looked inside the code but wasn't able to find a concrete cause. As starting point
for a possible problem I identified the following method in the AbstractEntityTuplizer
class:
public void setIdentifier(Object entity, Serializable id) throws HibernateException {
if ( entityMetamodel.getIdentifierProperty().isEmbedded() ) {
if ( entity != id ) {
AbstractComponentType copier = (AbstractComponentType)
entityMetamodel.getIdentifierProperty().getType();
copier.setPropertyValues( entity, copier.getPropertyValues( id, getEntityMode() ),
getEntityMode() );
}
}
else if ( idSetter != null ) {
idSetter.set( entity, id, getFactory() );
}
}
When I followed the methods
"entityMetamodel.getIdentifierProperty().isEmbedded()" up to the
AnnotationBinder class it seemded that the "isEmbedded()" method will always
return false. Even If the entity variable contains an entity with an embedded id class.
(Note: I saw the "PersistenceClass" container class containes an inner container
"IdentifiedProperty" with contains an EmbeddedContainerType but the embedded
flag is false!)
So if I'm right the first if-clause is never entered and for entities with embedded
ids the values are never set. And how can later the values be set at all elements of the
collection if the single element cannot be identified by the id (cause this variable is
still null)? Maybe that's a starting point for the failure search.
Incompleted Collection Returned from Joined Fetch
-------------------------------------------------
Key: HHH-3062
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3062
Project: Hibernate Core
Issue Type: Bug
Components: query-hql
Affects Versions: 3.2.5
Environment: Windows XP SP2, JDK 1.6_03, MySQL 5, Toncat 5.5.25
Reporter: Tony Lin
Attachments: org.zip, subsets.sql
Executing the following query:
select subset from com.alphait.domain.snomed.object.SubsetImpl as subset join fetch
subset.members as members left join fetch members.parent
The members returned after the first subset are not complete, all but the first member
are missing.
The classes are attached in HHH-3056. The test data is in the attached file, please load
it to a mysql database.
After investigation, the problem seems be in Loader.java's sequentialLoad method:
try {
do {
Object loaded = getRowFromResultSet(
resultSet,
session,
queryParameters,
getLockModes( queryParameters.getLockModes() ),
null,
hydratedObjects,
loadedKeys,
returnProxies
);
if ( result == null ) {
result = loaded;
}
}
while ( keyToRead.equals( loadedKeys[0] ) && resultSet.next() );
}
catch ( SQLException sqle ) {
throw JDBCExceptionHelper.convert(
factory.getSQLExceptionConverter(),
sqle,
"could not perform sequential read of results (forward)",
getSQLString()
);
}
initializeEntitiesAndCollections(
hydratedObjects,
resultSet,
session,
queryParameters.isReadOnly()
);
session.getPersistenceContext().initializeNonLazyCollections();
return result;
It will fetch the next subset also, but only the first member, and the member's
parent. These three are hydrated, and resolved when initializeEntitiesAndCollections is
called.
This makes the members collection to be freezed, and no member can be added.
We put the following:
key = getKeyFromResultSet(
0,
persisters[0],
null,
resultSet,
session
);
if (!keyToRead.equals(key)) { // we are done, no moving forward
break;
}
before calling getRowFromResultSet(). This temporarily solved the problem for us.
Also this kind of query cannot have order by containing only the members' properties
as it will return rows not ordered by Subset's ID. I think the HQL query parser should
not permit this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: