From: Mike D. (JIRA) <no...@at...> - 2006-05-02 17:04:27
|
AbstractEntityPersister causes an exception when a row in a joined table is missing with fetch="select" ------------------------------------------------------------------------------------------------------- Key: HHH-1713 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.3, 3.2.0 cr1 Environment: Hibernate 3.1.3, 3.2.0cr1 Oracle 9i (using odjbc14.jar from Oracle 10.1.0.4) Reporter: Mike Dillon Priority: Minor Attachments: AbstractEntityPersister.java.patch When using the <join> mapping, the behavior of AbstractEntityPersister when the joined row is missing is not consistent between fetch="join" and fetch="select". When fetch="join" and the row is missing, the AbstractEntityPersister simply sets all the outer joined fields to null since that's what comes back from the database. However, when fetch="select" and the row is missing, an SQLException is thrown. The reason is that the call to ResultSet.next() is not checked to see if a row is available before calling ResultSet.getXXXX(). In our Oracle enviroment, this resulted in a cryptic JDBC error about an "Exhausted Resultset". The fix is to check the return value of ResultSet.next(). I have attached a patch with a proposed fix for this issue. To be consistent with the current behavior of fetch="join", it explicitly sets all fields that come from the "sequential select" to null when the select does not produce any rows. This contradicts the hibernate-mapping DTD which says that the "optional" attribute on <join> defaults to false, but since that attribute is undocumented and the current implementation doesn't seem to respect this attribute even when fetch="join", I decided to be consistent with the actual semantics of fetch="join". The behavior of the optional attibute probably needs to be fixed in both cases, but I didn't address that with my patch. It seems that optional only works as advertised when Hibernate is able to produce a query with a single polymorphic join and can use an inner join instead of a left outer join. My patch was created against Hibernate 3.1.3, but I looked at the same code in 3.2.0cr1 and it has not changed. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Mike D. (JIRA) <no...@at...> - 2006-05-03 00:19:30
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713?page=comments#action_22961 ] Mike Dillon commented on HHH-1713: ---------------------------------- There is another unchecked use of ResultSet.next() in the same class that should probably be checked as well. That one is in initializeLazyPropertiesFromDatastore(). > AbstractEntityPersister causes an exception when a row in a joined table is missing with fetch="select" > ------------------------------------------------------------------------------------------------------- > > Key: HHH-1713 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.3, 3.2.0 cr1 > Environment: Hibernate 3.1.3, 3.2.0cr1 > Oracle 9i (using odjbc14.jar from Oracle 10.1.0.4) > Reporter: Mike Dillon > Priority: Minor > Attachments: AbstractEntityPersister.java.patch > > > When using the <join> mapping, the behavior of AbstractEntityPersister when the joined row is missing is not consistent between fetch="join" and fetch="select". > When fetch="join" and the row is missing, the AbstractEntityPersister simply sets all the outer joined fields to null since that's what comes back from the database. However, when fetch="select" and the row is missing, an SQLException is thrown. The reason is that the call to ResultSet.next() is not checked to see if a row is available before calling ResultSet.getXXXX(). In our Oracle enviroment, this resulted in a cryptic JDBC error about an "Exhausted Resultset". > The fix is to check the return value of ResultSet.next(). I have attached a patch with a proposed fix for this issue. To be consistent with the current behavior of fetch="join", it explicitly sets all fields that come from the "sequential select" to null when the select does not produce any rows. This contradicts the hibernate-mapping DTD which says that the "optional" attribute on <join> defaults to false, but since that attribute is undocumented and the current implementation doesn't seem to respect this attribute even when fetch="join", I decided to be consistent with the actual semantics of fetch="join". > The behavior of the optional attibute probably needs to be fixed in both cases, but I didn't address that with my patch. It seems that optional only works as advertised when Hibernate is able to produce a query with a single polymorphic join and can use an inner join instead of a left outer join. > My patch was created against Hibernate 3.1.3, but I looked at the same code in 3.2.0cr1 and it has not changed. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Mike D. (JIRA) <no...@at...> - 2006-05-09 18:44:29
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713?page=comments#action_23056 ] Mike Dillon commented on HHH-1713: ---------------------------------- This also affects the 3.2.0cr2 release, since the code in question is unchanged. > AbstractEntityPersister causes an exception when a row in a joined table is missing with fetch="select" > ------------------------------------------------------------------------------------------------------- > > Key: HHH-1713 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.3, 3.2.0 cr1 > Environment: Hibernate 3.1.3, 3.2.0cr1 > Oracle 9i (using odjbc14.jar from Oracle 10.1.0.4) > Reporter: Mike Dillon > Priority: Minor > Attachments: AbstractEntityPersister.java.patch > > > When using the <join> mapping, the behavior of AbstractEntityPersister when the joined row is missing is not consistent between fetch="join" and fetch="select". > When fetch="join" and the row is missing, the AbstractEntityPersister simply sets all the outer joined fields to null since that's what comes back from the database. However, when fetch="select" and the row is missing, an SQLException is thrown. The reason is that the call to ResultSet.next() is not checked to see if a row is available before calling ResultSet.getXXXX(). In our Oracle enviroment, this resulted in a cryptic JDBC error about an "Exhausted Resultset". > The fix is to check the return value of ResultSet.next(). I have attached a patch with a proposed fix for this issue. To be consistent with the current behavior of fetch="join", it explicitly sets all fields that come from the "sequential select" to null when the select does not produce any rows. This contradicts the hibernate-mapping DTD which says that the "optional" attribute on <join> defaults to false, but since that attribute is undocumented and the current implementation doesn't seem to respect this attribute even when fetch="join", I decided to be consistent with the actual semantics of fetch="join". > The behavior of the optional attibute probably needs to be fixed in both cases, but I didn't address that with my patch. It seems that optional only works as advertised when Hibernate is able to produce a query with a single polymorphic join and can use an inner join instead of a left outer join. > My patch was created against Hibernate 3.1.3, but I looked at the same code in 3.2.0cr1 and it has not changed. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Serge P. N. (JIRA) <no...@at...> - 2006-05-10 11:01:29
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713?page=all ] Serge P. Nekoval updated HHH-1713: ---------------------------------- Attachment: BasicEntityPersister.patch > AbstractEntityPersister causes an exception when a row in a joined table is missing with fetch="select" > ------------------------------------------------------------------------------------------------------- > > Key: HHH-1713 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.3, 3.2.0 cr1 > Environment: Hibernate 3.1.3, 3.2.0cr1 > Oracle 9i (using odjbc14.jar from Oracle 10.1.0.4) > Reporter: Mike Dillon > Priority: Minor > Attachments: AbstractEntityPersister.java.patch, BasicEntityPersister.patch > > > When using the <join> mapping, the behavior of AbstractEntityPersister when the joined row is missing is not consistent between fetch="join" and fetch="select". > When fetch="join" and the row is missing, the AbstractEntityPersister simply sets all the outer joined fields to null since that's what comes back from the database. However, when fetch="select" and the row is missing, an SQLException is thrown. The reason is that the call to ResultSet.next() is not checked to see if a row is available before calling ResultSet.getXXXX(). In our Oracle enviroment, this resulted in a cryptic JDBC error about an "Exhausted Resultset". > The fix is to check the return value of ResultSet.next(). I have attached a patch with a proposed fix for this issue. To be consistent with the current behavior of fetch="join", it explicitly sets all fields that come from the "sequential select" to null when the select does not produce any rows. This contradicts the hibernate-mapping DTD which says that the "optional" attribute on <join> defaults to false, but since that attribute is undocumented and the current implementation doesn't seem to respect this attribute even when fetch="join", I decided to be consistent with the actual semantics of fetch="join". > The behavior of the optional attibute probably needs to be fixed in both cases, but I didn't address that with my patch. It seems that optional only works as advertised when Hibernate is able to produce a query with a single polymorphic join and can use an inner join instead of a left outer join. > My patch was created against Hibernate 3.1.3, but I looked at the same code in 3.2.0cr1 and it has not changed. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Serge P. N. (JIRA) <no...@at...> - 2006-05-10 11:03:25
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713?page=comments#action_23060 ] Serge P. Nekoval commented on HHH-1713: --------------------------------------- Hi, I've generated a patch for Hibernate 3.0.5, since we're unable to upgrade to 3.1 so far. Attached. Seems to work fine. > AbstractEntityPersister causes an exception when a row in a joined table is missing with fetch="select" > ------------------------------------------------------------------------------------------------------- > > Key: HHH-1713 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.3, 3.2.0 cr1 > Environment: Hibernate 3.1.3, 3.2.0cr1 > Oracle 9i (using odjbc14.jar from Oracle 10.1.0.4) > Reporter: Mike Dillon > Priority: Minor > Attachments: AbstractEntityPersister.java.patch, BasicEntityPersister.patch > > > When using the <join> mapping, the behavior of AbstractEntityPersister when the joined row is missing is not consistent between fetch="join" and fetch="select". > When fetch="join" and the row is missing, the AbstractEntityPersister simply sets all the outer joined fields to null since that's what comes back from the database. However, when fetch="select" and the row is missing, an SQLException is thrown. The reason is that the call to ResultSet.next() is not checked to see if a row is available before calling ResultSet.getXXXX(). In our Oracle enviroment, this resulted in a cryptic JDBC error about an "Exhausted Resultset". > The fix is to check the return value of ResultSet.next(). I have attached a patch with a proposed fix for this issue. To be consistent with the current behavior of fetch="join", it explicitly sets all fields that come from the "sequential select" to null when the select does not produce any rows. This contradicts the hibernate-mapping DTD which says that the "optional" attribute on <join> defaults to false, but since that attribute is undocumented and the current implementation doesn't seem to respect this attribute even when fetch="join", I decided to be consistent with the actual semantics of fetch="join". > The behavior of the optional attibute probably needs to be fixed in both cases, but I didn't address that with my patch. It seems that optional only works as advertised when Hibernate is able to produce a query with a single polymorphic join and can use an inner join instead of a left outer join. > My patch was created against Hibernate 3.1.3, but I looked at the same code in 3.2.0cr1 and it has not changed. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Mike D. (JIRA) <no...@at...> - 2006-07-13 06:03:58
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713?page=comments#action_23615 ] Mike Dillon commented on HHH-1713: ---------------------------------- Hey there. I see that there was a commit to AbstractEntityPersister two days ago, so I was wondering if someone on the Hibernate team would mind taking another look at this patch. It looks like the issue is still there on the trunk of SVN. Thanks in advance. > AbstractEntityPersister causes an exception when a row in a joined table is missing with fetch="select" > ------------------------------------------------------------------------------------------------------- > > Key: HHH-1713 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.3, 3.2.0 cr1 > Environment: Hibernate 3.1.3, 3.2.0cr1 > Oracle 9i (using odjbc14.jar from Oracle 10.1.0.4) > Reporter: Mike Dillon > Priority: Minor > Attachments: AbstractEntityPersister.java.patch, BasicEntityPersister.patch > > > When using the <join> mapping, the behavior of AbstractEntityPersister when the joined row is missing is not consistent between fetch="join" and fetch="select". > When fetch="join" and the row is missing, the AbstractEntityPersister simply sets all the outer joined fields to null since that's what comes back from the database. However, when fetch="select" and the row is missing, an SQLException is thrown. The reason is that the call to ResultSet.next() is not checked to see if a row is available before calling ResultSet.getXXXX(). In our Oracle enviroment, this resulted in a cryptic JDBC error about an "Exhausted Resultset". > The fix is to check the return value of ResultSet.next(). I have attached a patch with a proposed fix for this issue. To be consistent with the current behavior of fetch="join", it explicitly sets all fields that come from the "sequential select" to null when the select does not produce any rows. This contradicts the hibernate-mapping DTD which says that the "optional" attribute on <join> defaults to false, but since that attribute is undocumented and the current implementation doesn't seem to respect this attribute even when fetch="join", I decided to be consistent with the actual semantics of fetch="join". > The behavior of the optional attibute probably needs to be fixed in both cases, but I didn't address that with my patch. It seems that optional only works as advertised when Hibernate is able to produce a query with a single polymorphic join and can use an inner join instead of a left outer join. > My patch was created against Hibernate 3.1.3, but I looked at the same code in 3.2.0cr1 and it has not changed. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Steve E. (JIRA) <no...@at...> - 2006-07-26 17:21:13
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713?page=all ] Steve Ebersole resolved HHH-1713: --------------------------------- Fix Version: 3.2.0.ga Resolution: Fixed Assign To: Steve Ebersole applied on head and 3.2 branch > AbstractEntityPersister causes an exception when a row in a joined table is missing with fetch="select" > ------------------------------------------------------------------------------------------------------- > > Key: HHH-1713 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.3, 3.2.0 cr1 > Environment: Hibernate 3.1.3, 3.2.0cr1 > Oracle 9i (using odjbc14.jar from Oracle 10.1.0.4) > Reporter: Mike Dillon > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.2.0.ga > Attachments: AbstractEntityPersister.java.patch, AbstractEntityPersister.java.patch, BasicEntityPersister.patch > > > When using the <join> mapping, the behavior of AbstractEntityPersister when the joined row is missing is not consistent between fetch="join" and fetch="select". > When fetch="join" and the row is missing, the AbstractEntityPersister simply sets all the outer joined fields to null since that's what comes back from the database. However, when fetch="select" and the row is missing, an SQLException is thrown. The reason is that the call to ResultSet.next() is not checked to see if a row is available before calling ResultSet.getXXXX(). In our Oracle enviroment, this resulted in a cryptic JDBC error about an "Exhausted Resultset". > The fix is to check the return value of ResultSet.next(). I have attached a patch with a proposed fix for this issue. To be consistent with the current behavior of fetch="join", it explicitly sets all fields that come from the "sequential select" to null when the select does not produce any rows. This contradicts the hibernate-mapping DTD which says that the "optional" attribute on <join> defaults to false, but since that attribute is undocumented and the current implementation doesn't seem to respect this attribute even when fetch="join", I decided to be consistent with the actual semantics of fetch="join". > The behavior of the optional attibute probably needs to be fixed in both cases, but I didn't address that with my patch. It seems that optional only works as advertised when Hibernate is able to produce a query with a single polymorphic join and can use an inner join instead of a left outer join. > My patch was created against Hibernate 3.1.3, but I looked at the same code in 3.2.0cr1 and it has not changed. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Mike D. (JIRA) <no...@at...> - 2006-07-27 17:29:26
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713?page=all ] Mike Dillon updated HHH-1713: ----------------------------- Attachment: AbstractEntityPersister.java.patch Updated patch from SVN trunk of Hibernate3. > AbstractEntityPersister causes an exception when a row in a joined table is missing with fetch="select" > ------------------------------------------------------------------------------------------------------- > > Key: HHH-1713 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.3, 3.2.0 cr1 > Environment: Hibernate 3.1.3, 3.2.0cr1 > Oracle 9i (using odjbc14.jar from Oracle 10.1.0.4) > Reporter: Mike Dillon > Priority: Minor > Attachments: AbstractEntityPersister.java.patch, AbstractEntityPersister.java.patch, BasicEntityPersister.patch > > > When using the <join> mapping, the behavior of AbstractEntityPersister when the joined row is missing is not consistent between fetch="join" and fetch="select". > When fetch="join" and the row is missing, the AbstractEntityPersister simply sets all the outer joined fields to null since that's what comes back from the database. However, when fetch="select" and the row is missing, an SQLException is thrown. The reason is that the call to ResultSet.next() is not checked to see if a row is available before calling ResultSet.getXXXX(). In our Oracle enviroment, this resulted in a cryptic JDBC error about an "Exhausted Resultset". > The fix is to check the return value of ResultSet.next(). I have attached a patch with a proposed fix for this issue. To be consistent with the current behavior of fetch="join", it explicitly sets all fields that come from the "sequential select" to null when the select does not produce any rows. This contradicts the hibernate-mapping DTD which says that the "optional" attribute on <join> defaults to false, but since that attribute is undocumented and the current implementation doesn't seem to respect this attribute even when fetch="join", I decided to be consistent with the actual semantics of fetch="join". > The behavior of the optional attibute probably needs to be fixed in both cases, but I didn't address that with my patch. It seems that optional only works as advertised when Hibernate is able to produce a query with a single polymorphic join and can use an inner join instead of a left outer join. > My patch was created against Hibernate 3.1.3, but I looked at the same code in 3.2.0cr1 and it has not changed. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |