[Hibernate-JIRA] Created: (HHH-6405) setFetchMode ignored in certain cases when using criteria queries
3:17 p.m.
setFetchMode ignored in certain cases when using criteria queries
-----------------------------------------------------------------
Key: HHH-6405
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6405
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 4.0.0.Beta2, 3.6.5
Reporter: David Mansfield
Description:
Setting join type (e.g.) criteria.setJoinType("association.path",
FetchType.JOIN) is ignored if the association being set is one of a few types. I believe
many-to-many, and any association off of a collection-of-component. For these types of
associations, the specified fetch type is ignored.
This worked in prior versions.
This has nothing to do with having additional restrictions on the same association, which
is a different issue altogether.
Technical analysis:
This regression was introduced in git commit fbae6db0abaeb6f050ee97ce53d09d74886a7e47, and
the fix for a possibly related issue in git commit
1c556dc775708706b6ca84251cb170d3c46f729f was not a complete fix, or rather did not fix
this case scenario.
The first referenced commit split the JoinWalker.getJoinType(...) api into two methods,
one with more parameters. In the base class implementation, one method or the other is
called based on the type of association (see above). However, in the CriteriaJoinWalker
(a subclass), the existing implementation only overrode one of these two methods, (the one
with more arguments) causing calls into the other method to be handled by the base class,
which did not function appropriately.
The second referenced commit introduced an override for the second method, however the
implementation was incomplete, and was missing the crucial piece, specifically:
FetchMode fetchMode = translator.getRootCriteria().getFetchMode( path.getFullPath() );
which examined the explicitly set join types in the translator.
A fix will be supplied on github for 3.6.x and 4.0.
The implementation re-unifies the two methods in the CriteriaJoinWalker, using if/else to
delegate to the correct super.getJoinType(...) method as appropriate.
--
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
9:38 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-6405) setFetchMode ignored in certain cases when using criteria queries
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6405?page=c...
]
David Mansfield commented on HHH-6405:
--------------------------------------
Note, in the above I said setJoinType, should have said setFetchMode (as the subject
correctly states).
A 3.6 pull request is at: https://github.com/hibernate/hibernate-core/pull/122
setFetchMode ignored in certain cases when using criteria queries
-----------------------------------------------------------------
Key: HHH-6405
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6405
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.6.5, 4.0.0.Beta2
Reporter: David Mansfield
Description:
Setting join type (e.g.) criteria.setJoinType("association.path",
FetchType.JOIN) is ignored if the association being set is one of a few types. I believe
many-to-many, and any association off of a collection-of-component. For these types of
associations, the specified fetch type is ignored.
This worked in prior versions.
This has nothing to do with having additional restrictions on the same association, which
is a different issue altogether.
Technical analysis:
This regression was introduced in git commit fbae6db0abaeb6f050ee97ce53d09d74886a7e47,
and the fix for a possibly related issue in git commit
1c556dc775708706b6ca84251cb170d3c46f729f was not a complete fix, or rather did not fix
this case scenario.
The first referenced commit split the JoinWalker.getJoinType(...) api into two methods,
one with more parameters. In the base class implementation, one method or the other is
called based on the type of association (see above). However, in the CriteriaJoinWalker
(a subclass), the existing implementation only overrode one of these two methods, (the one
with more arguments) causing calls into the other method to be handled by the base class,
which did not function appropriately.
The second referenced commit introduced an override for the second method, however the
implementation was incomplete, and was missing the crucial piece, specifically:
FetchMode fetchMode = translator.getRootCriteria().getFetchMode( path.getFullPath() );
which examined the explicitly set join types in the translator.
A fix will be supplied on github for 3.6.x and 4.0.
The implementation re-unifies the two methods in the CriteriaJoinWalker, using if/else to
delegate to the correct super.getJoinType(...) method as appropriate.
--
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
2:06 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-6405) setFetchMode ignored in certain cases when using criteria queries
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6405?page=c...
]
David Mansfield commented on HHH-6405:
--------------------------------------
A 4.0 pull request is at: https://github.com/hibernate/hibernate-core/pull/127
setFetchMode ignored in certain cases when using criteria queries
-----------------------------------------------------------------
Key: HHH-6405
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6405
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.6.5, 4.0.0.Beta2
Reporter: David Mansfield
Description:
Setting join type (e.g.) criteria.setJoinType("association.path",
FetchType.JOIN) is ignored if the association being set is one of a few types. I believe
many-to-many, and any association off of a collection-of-component. For these types of
associations, the specified fetch type is ignored.
This worked in prior versions.
This has nothing to do with having additional restrictions on the same association, which
is a different issue altogether.
Technical analysis:
This regression was introduced in git commit fbae6db0abaeb6f050ee97ce53d09d74886a7e47,
and the fix for a possibly related issue in git commit
1c556dc775708706b6ca84251cb170d3c46f729f was not a complete fix, or rather did not fix
this case scenario.
The first referenced commit split the JoinWalker.getJoinType(...) api into two methods,
one with more parameters. In the base class implementation, one method or the other is
called based on the type of association (see above). However, in the CriteriaJoinWalker
(a subclass), the existing implementation only overrode one of these two methods, (the one
with more arguments) causing calls into the other method to be handled by the base class,
which did not function appropriately.
The second referenced commit introduced an override for the second method, however the
implementation was incomplete, and was missing the crucial piece, specifically:
FetchMode fetchMode = translator.getRootCriteria().getFetchMode( path.getFullPath() );
which examined the explicitly set join types in the translator.
A fix will be supplied on github for 3.6.x and 4.0.
The implementation re-unifies the two methods in the CriteriaJoinWalker, using if/else to
delegate to the correct super.getJoinType(...) method as appropriate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:02 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-6405) setFetchMode ignored in certain cases when using criteria queries
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6405?page=c...
]
Gail Badner updated HHH-6405:
-----------------------------
Issue Type: Patch (was: Bug)
setFetchMode ignored in certain cases when using criteria queries
-----------------------------------------------------------------
Key: HHH-6405
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6405
Project: Hibernate Core
Issue Type: Patch
Affects Versions: 3.6.5, 4.0.0.Beta2
Reporter: David Mansfield
Description:
Setting join type (e.g.) criteria.setJoinType("association.path",
FetchType.JOIN) is ignored if the association being set is one of a few types. I believe
many-to-many, and any association off of a collection-of-component. For these types of
associations, the specified fetch type is ignored.
This worked in prior versions.
This has nothing to do with having additional restrictions on the same association, which
is a different issue altogether.
Technical analysis:
This regression was introduced in git commit fbae6db0abaeb6f050ee97ce53d09d74886a7e47,
and the fix for a possibly related issue in git commit
1c556dc775708706b6ca84251cb170d3c46f729f was not a complete fix, or rather did not fix
this case scenario.
The first referenced commit split the JoinWalker.getJoinType(...) api into two methods,
one with more parameters. In the base class implementation, one method or the other is
called based on the type of association (see above). However, in the CriteriaJoinWalker
(a subclass), the existing implementation only overrode one of these two methods, (the one
with more arguments) causing calls into the other method to be handled by the base class,
which did not function appropriately.
The second referenced commit introduced an override for the second method, however the
implementation was incomplete, and was missing the crucial piece, specifically:
FetchMode fetchMode = translator.getRootCriteria().getFetchMode( path.getFullPath() );
which examined the explicitly set join types in the translator.
A fix will be supplied on github for 3.6.x and 4.0.
The implementation re-unifies the two methods in the CriteriaJoinWalker, using if/else to
delegate to the correct super.getJoinType(...) method as appropriate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:28 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-6405) setFetchMode ignored in certain cases when using criteria queries
[
https://hibernate.onjira.com/browse/HHH-6405?page=com.atlassian.jira.plug...
]
Steve Ebersole updated HHH-6405:
--------------------------------
Pull Requests: https://github.com/hibernate/hibernate-orm/pull/127
setFetchMode ignored in certain cases when using criteria queries
-----------------------------------------------------------------
Key: HHH-6405
URL: https://hibernate.onjira.com/browse/HHH-6405
Project: Hibernate ORM
Issue Type: Patch
Affects Versions: 3.6.5, 4.0.0.Beta2
Reporter: David Mansfield
Description:
Setting join type (e.g.) criteria.setJoinType("association.path",
FetchType.JOIN) is ignored if the association being set is one of a few types. I believe
many-to-many, and any association off of a collection-of-component. For these types of
associations, the specified fetch type is ignored.
This worked in prior versions.
This has nothing to do with having additional restrictions on the same association, which
is a different issue altogether.
Technical analysis:
This regression was introduced in git commit fbae6db0abaeb6f050ee97ce53d09d74886a7e47,
and the fix for a possibly related issue in git commit
1c556dc775708706b6ca84251cb170d3c46f729f was not a complete fix, or rather did not fix
this case scenario.
The first referenced commit split the JoinWalker.getJoinType(...) api into two methods,
one with more parameters. In the base class implementation, one method or the other is
called based on the type of association (see above). However, in the CriteriaJoinWalker
(a subclass), the existing implementation only overrode one of these two methods, (the one
with more arguments) causing calls into the other method to be handled by the base class,
which did not function appropriately.
The second referenced commit introduced an override for the second method, however the
implementation was incomplete, and was missing the crucial piece, specifically:
FetchMode fetchMode = translator.getRootCriteria().getFetchMode( path.getFullPath() );
which examined the explicitly set join types in the translator.
A fix will be supplied on github for 3.6.x and 4.0.
The implementation re-unifies the two methods in the CriteriaJoinWalker, using if/else to
delegate to the correct super.getJoinType(...) method as appropriate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:30 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-6405) setFetchMode ignored in certain cases when using criteria queries
[
https://hibernate.onjira.com/browse/HHH-6405?page=com.atlassian.jira.plug...
]
Steve Ebersole updated HHH-6405:
--------------------------------
Pull Requests: https://github.com/hibernate/hibernate-orm/pull/127 (was:
https://github.com/hibernate/hibernate-orm/pull/127)
Assignee: Steve Ebersole
setFetchMode ignored in certain cases when using criteria queries
-----------------------------------------------------------------
Key: HHH-6405
URL: https://hibernate.onjira.com/browse/HHH-6405
Project: Hibernate ORM
Issue Type: Patch
Affects Versions: 3.6.5, 4.0.0.Beta2
Reporter: David Mansfield
Assignee: Steve Ebersole
Description:
Setting join type (e.g.) criteria.setJoinType("association.path",
FetchType.JOIN) is ignored if the association being set is one of a few types. I believe
many-to-many, and any association off of a collection-of-component. For these types of
associations, the specified fetch type is ignored.
This worked in prior versions.
This has nothing to do with having additional restrictions on the same association, which
is a different issue altogether.
Technical analysis:
This regression was introduced in git commit fbae6db0abaeb6f050ee97ce53d09d74886a7e47,
and the fix for a possibly related issue in git commit
1c556dc775708706b6ca84251cb170d3c46f729f was not a complete fix, or rather did not fix
this case scenario.
The first referenced commit split the JoinWalker.getJoinType(...) api into two methods,
one with more parameters. In the base class implementation, one method or the other is
called based on the type of association (see above). However, in the CriteriaJoinWalker
(a subclass), the existing implementation only overrode one of these two methods, (the one
with more arguments) causing calls into the other method to be handled by the base class,
which did not function appropriately.
The second referenced commit introduced an override for the second method, however the
implementation was incomplete, and was missing the crucial piece, specifically:
FetchMode fetchMode = translator.getRootCriteria().getFetchMode( path.getFullPath() );
which examined the explicitly set join types in the translator.
A fix will be supplied on github for 3.6.x and 4.0.
The implementation re-unifies the two methods in the CriteriaJoinWalker, using if/else to
delegate to the correct super.getJoinType(...) method as appropriate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:07 p.m.
New subject: [Hibernate-JIRA] Resolved: (HHH-6405) setFetchMode ignored in certain cases when using criteria queries
[
https://hibernate.onjira.com/browse/HHH-6405?page=com.atlassian.jira.plug...
]
Steve Ebersole resolved HHH-6405.
---------------------------------
Resolution: Fixed
Fix Version/s: 4.1.3
setFetchMode ignored in certain cases when using criteria queries
-----------------------------------------------------------------
Key: HHH-6405
URL: https://hibernate.onjira.com/browse/HHH-6405
Project: Hibernate ORM
Issue Type: Patch
Affects Versions: 3.6.5, 4.0.0.Beta2
Reporter: David Mansfield
Assignee: Steve Ebersole
Fix For: 4.1.3
Time Spent: 1.6h
Description:
Setting join type (e.g.) criteria.setJoinType("association.path",
FetchType.JOIN) is ignored if the association being set is one of a few types. I believe
many-to-many, and any association off of a collection-of-component. For these types of
associations, the specified fetch type is ignored.
This worked in prior versions.
This has nothing to do with having additional restrictions on the same association, which
is a different issue altogether.
Technical analysis:
This regression was introduced in git commit fbae6db0abaeb6f050ee97ce53d09d74886a7e47,
and the fix for a possibly related issue in git commit
1c556dc775708706b6ca84251cb170d3c46f729f was not a complete fix, or rather did not fix
this case scenario.
The first referenced commit split the JoinWalker.getJoinType(...) api into two methods,
one with more parameters. In the base class implementation, one method or the other is
called based on the type of association (see above). However, in the CriteriaJoinWalker
(a subclass), the existing implementation only overrode one of these two methods, (the one
with more arguments) causing calls into the other method to be handled by the base class,
which did not function appropriately.
The second referenced commit introduced an override for the second method, however the
implementation was incomplete, and was missing the crucial piece, specifically:
FetchMode fetchMode = translator.getRootCriteria().getFetchMode( path.getFullPath() );
which examined the explicitly set join types in the translator.
A fix will be supplied on github for 3.6.x and 4.0.
The implementation re-unifies the two methods in the CriteriaJoinWalker, using if/else to
delegate to the correct super.getJoinType(...) method as appropriate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:20 p.m.
New subject: [Hibernate-JIRA] Reopened: (HHH-6405) setFetchMode ignored in certain cases when using criteria queries
[
https://hibernate.onjira.com/browse/HHH-6405?page=com.atlassian.jira.plug...
]
Strong Liu reopened HHH-6405:
-----------------------------
_org.hibernate.test.criteria.CriteriaQueryTest_ fails on oracle due to
"org.hibernate.exception.SQLGrammarException: ORA-00942: table or view does not
exist"
{quote}
23:37:27,167 ERROR SchemaExport:425 - HHH000389: Unsuccessful: create table
Student_studyAbroads (studentId number(19,0) not null, date timestamp, country
varchar2(255 char), ind number(10,0) not null, primary key (studentId, ind))
23:37:27,168 ERROR SchemaExport:426 - ORA-00904: : invalid identifier
{quote}
setFetchMode ignored in certain cases when using criteria queries
-----------------------------------------------------------------
Key: HHH-6405
URL: https://hibernate.onjira.com/browse/HHH-6405
Project: Hibernate ORM
Issue Type: Patch
Affects Versions: 3.6.5, 4.0.0.Beta2
Reporter: David Mansfield
Assignee: Steve Ebersole
Fix For: 4.1.3
Time Spent: 1.6h
Description:
Setting join type (e.g.) criteria.setJoinType("association.path",
FetchType.JOIN) is ignored if the association being set is one of a few types. I believe
many-to-many, and any association off of a collection-of-component. For these types of
associations, the specified fetch type is ignored.
This worked in prior versions.
This has nothing to do with having additional restrictions on the same association, which
is a different issue altogether.
Technical analysis:
This regression was introduced in git commit fbae6db0abaeb6f050ee97ce53d09d74886a7e47,
and the fix for a possibly related issue in git commit
1c556dc775708706b6ca84251cb170d3c46f729f was not a complete fix, or rather did not fix
this case scenario.
The first referenced commit split the JoinWalker.getJoinType(...) api into two methods,
one with more parameters. In the base class implementation, one method or the other is
called based on the type of association (see above). However, in the CriteriaJoinWalker
(a subclass), the existing implementation only overrode one of these two methods, (the one
with more arguments) causing calls into the other method to be handled by the base class,
which did not function appropriately.
The second referenced commit introduced an override for the second method, however the
implementation was incomplete, and was missing the crucial piece, specifically:
FetchMode fetchMode = translator.getRootCriteria().getFetchMode( path.getFullPath() );
which examined the explicitly set join types in the translator.
A fix will be supplied on github for 3.6.x and 4.0.
The implementation re-unifies the two methods in the CriteriaJoinWalker, using if/else to
delegate to the correct super.getJoinType(...) method as appropriate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:26 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-6405) setFetchMode ignored in certain cases when using criteria queries
[
https://hibernate.onjira.com/browse/HHH-6405?page=com.atlassian.jira.plug...
]
David Mansfield commented on HHH-6405:
--------------------------------------
I only have ever used annotations. How does one in mapping XML specify the column name
for a property? In
hibernate-testsuite/src/test/java/org/hibernate/test/criteria/Enrolment.hbm.xml a column
for the "date" property needs to be specified, as "date" is an illegal
column name (for oracle, but not apparently in the default test suite db).
Can you try it with specifying a colunn name, like 'dte' .
setFetchMode ignored in certain cases when using criteria queries
-----------------------------------------------------------------
Key: HHH-6405
URL: https://hibernate.onjira.com/browse/HHH-6405
Project: Hibernate ORM
Issue Type: Patch
Affects Versions: 3.6.5, 4.0.0.Beta2
Reporter: David Mansfield
Assignee: Steve Ebersole
Fix For: 4.1.3
Time Spent: 1.6h
Description:
Setting join type (e.g.) criteria.setJoinType("association.path",
FetchType.JOIN) is ignored if the association being set is one of a few types. I believe
many-to-many, and any association off of a collection-of-component. For these types of
associations, the specified fetch type is ignored.
This worked in prior versions.
This has nothing to do with having additional restrictions on the same association, which
is a different issue altogether.
Technical analysis:
This regression was introduced in git commit fbae6db0abaeb6f050ee97ce53d09d74886a7e47,
and the fix for a possibly related issue in git commit
1c556dc775708706b6ca84251cb170d3c46f729f was not a complete fix, or rather did not fix
this case scenario.
The first referenced commit split the JoinWalker.getJoinType(...) api into two methods,
one with more parameters. In the base class implementation, one method or the other is
called based on the type of association (see above). However, in the CriteriaJoinWalker
(a subclass), the existing implementation only overrode one of these two methods, (the one
with more arguments) causing calls into the other method to be handled by the base class,
which did not function appropriately.
The second referenced commit introduced an override for the second method, however the
implementation was incomplete, and was missing the crucial piece, specifically:
FetchMode fetchMode = translator.getRootCriteria().getFetchMode( path.getFullPath() );
which examined the explicitly set join types in the translator.
A fix will be supplied on github for 3.6.x and 4.0.
The implementation re-unifies the two methods in the CriteriaJoinWalker, using if/else to
delegate to the correct super.getJoinType(...) method as appropriate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:47 a.m.
New subject: [Hibernate-JIRA] Resolved: (HHH-6405) setFetchMode ignored in certain cases when using criteria queries
[
https://hibernate.onjira.com/browse/HHH-6405?page=com.atlassian.jira.plug...
]
Steve Ebersole resolved HHH-6405.
---------------------------------
Resolution: Fixed
setFetchMode ignored in certain cases when using criteria queries
-----------------------------------------------------------------
Key: HHH-6405
URL: https://hibernate.onjira.com/browse/HHH-6405
Project: Hibernate ORM
Issue Type: Patch
Affects Versions: 3.6.5, 4.0.0.Beta2
Reporter: David Mansfield
Assignee: Steve Ebersole
Fix For: 4.1.3
Time Spent: 1h 38m
Description:
Setting join type (e.g.) criteria.setJoinType("association.path",
FetchType.JOIN) is ignored if the association being set is one of a few types. I believe
many-to-many, and any association off of a collection-of-component. For these types of
associations, the specified fetch type is ignored.
This worked in prior versions.
This has nothing to do with having additional restrictions on the same association, which
is a different issue altogether.
Technical analysis:
This regression was introduced in git commit fbae6db0abaeb6f050ee97ce53d09d74886a7e47,
and the fix for a possibly related issue in git commit
1c556dc775708706b6ca84251cb170d3c46f729f was not a complete fix, or rather did not fix
this case scenario.
The first referenced commit split the JoinWalker.getJoinType(...) api into two methods,
one with more parameters. In the base class implementation, one method or the other is
called based on the type of association (see above). However, in the CriteriaJoinWalker
(a subclass), the existing implementation only overrode one of these two methods, (the one
with more arguments) causing calls into the other method to be handled by the base class,
which did not function appropriately.
The second referenced commit introduced an override for the second method, however the
implementation was incomplete, and was missing the crucial piece, specifically:
FetchMode fetchMode = translator.getRootCriteria().getFetchMode( path.getFullPath() );
which examined the explicitly set join types in the translator.
A fix will be supplied on github for 3.6.x and 4.0.
The implementation re-unifies the two methods in the CriteriaJoinWalker, using if/else to
delegate to the correct super.getJoinType(...) method as appropriate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
5102
days inactive
5398
days old
hibernate-issues@lists.jboss.org
9 comments
4 participants
participants (4)
-
David Mansfield (JIRA) -
Gail Badner (JIRA)
-
Steve Ebersole (JIRA)
-
Strong Liu (JIRA)