[Hibernate-JIRA] Commented: (HHH-1283) ScrollableResults JoinFetch don't set child collection correctly after the second parent object
by Ivan Malygin (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1283?page=c... ]
Ivan Malygin commented on HHH-1283:
-----------------------------------
I'm also confirming the bug. I think this bug, because it makes Criteria API useless for the cases with one-to-many relations.
> ScrollableResults JoinFetch don't set child collection correctly after the second parent object
> -----------------------------------------------------------------------------------------------
>
> Key: HHH-1283
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1283
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1
> Environment: Hibernate 3.1
> Oracle10gR2
> Oracle JDBC Driver 10.2.0.1.0
> Sun JDK 1.5.0_06
> Spring 1.2.6
> Reporter: Masahiro Hirashima
> Attachments: ScrollableCollectionFetchingTest.java, ScrollableResults.zip
>
>
> ScrollableResults JoinFetch set child collection correctly at first parent object.
> but after the second parent object, It set only the first element of a child collection.
> I made the following tables.
> CREATE TABLE owners (
> id NUMBER(36, 0) NOT NULL PRIMARY KEY,
> first_name VARCHAR(30),
> last_name VARCHAR(30),
> address VARCHAR(255),
> city VARCHAR(80),
> telephone VARCHAR(20),
> version NUMBER(36, 0) DEFAULT 0
> );
> CREATE TABLE types (
> id NUMBER(36, 0) NOT NULL PRIMARY KEY,
> name VARCHAR(80),
> version NUMBER(36, 0) DEFAULT 0
> );
> CREATE TABLE pets (
> id NUMBER(36, 0) NOT NULL PRIMARY KEY,
> name VARCHAR(30),
> birth_date DATE,
> type_id NUMBER(36, 0),
> owner_id NUMBER(36, 0),
> version NUMBER(36, 0) DEFAULT 0
> );
> and inserted the following data.
> INSERT INTO owners VALUES (1, 'Betty', 'Davis', '638 Cardinal Ave.', 'Sun Prairie', '6085551749', 0);
> INSERT INTO owners VALUES (2, 'Eduardo', 'Rodriquez', '2693 Commerce St.', 'McFarland', '6085558763', 0);
> INSERT INTO pets VALUES (1, 'Leo', '2000-09-07', 1, 1, 0);
> INSERT INTO pets VALUES (2, 'Basil', '2002-08-06', 2, 1, 0);
> INSERT INTO pets VALUES (3, 'Rosy', '2001-04-17', 3, 2, 0);
> INSERT INTO pets VALUES (4, 'Jewel', '2000-03-07', 4, 2, 0);
> INSERT INTO pets VALUES (5, 'Iggy', '2000-11-30', 5, 2, 0);
> INSERT INTO types VALUES (1, 'cat', 0);
> INSERT INTO types VALUES (2, 'dog', 0);
> INSERT INTO types VALUES (3, 'lizard', 0);
> INSERT INTO types VALUES (4, 'snake', 0);
> INSERT INTO types VALUES (5, 'bird', 0);
> and I execute following code.
> String hqlJoinFetchTest =
> "from Owner owner " +
> "left outer join fetch owner.pets as pets " +
> "left outer join fetch pets.type " +
> "order by owner.firstName, owner.lastName";
> Query query = session.createQuery(hqlJoinFetchTest);
> ScrollableResults cursor = query.scroll();
> while ( cursor.next() ) {
> Owner owner = (Owner)cursor.get(0);
> System.out.println(owner);
> }
> result of this code is following.
> petclinic.domain.Owner@15d616e[id=1,version=0,firstName=Betty,lastName=Davis,
> petclinic.domain.Pet@136d9d8[id=2,version=0,name=Basil,birthDate=2002-08-06,
> petclinic.domain.PetType@1be2893[id=2,version=0,name=dog]
> petclinic.domain.Pet@14a75bb[id=1,version=0,name=Leo,birthDate=2000-09-07,
> petclinic.domain.PetType@17779e3[id=1,version=0,name=cat]
> petclinic.domain.Owner@e3570c[id=2,version=0,firstName=Eduardo,lastName=Rodriquez
> petclinic.domain.Pet@167e3a5[id=4,version=0,name=Jewel,birthDate=2000-03-07,
> petclinic.domain.PetType@1926e90[id=4,version=0,name=snake]
> First owner object set collection collectly.
> but second owner object don't set second pet object(id=5) and third pet object(id=6).
--
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
16 years
[Hibernate-JIRA] Created: (HHH-3442) StaleObjectStateException logs unnecessary stacktrace
by Tom van den Berge (JIRA)
StaleObjectStateException logs unnecessary stacktrace
-----------------------------------------------------
Key: HHH-3442
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3442
Project: Hibernate3
Issue Type: Improvement
Affects Versions: 3.3.0.GA
Reporter: Tom van den Berge
Priority: Minor
When using optimistic locking, and stale state is detected, a StaleObjectStateException is thrown. This exception is caught in AbstractFlushingEventListener, logged as error, including a stacktrace, and then thrown again.
It would be better not to log the stacktrace in this situation, since it's up to the client code to deal with the exception. If the client code doesn't handle optimistic locking exceptions, it can choose to log the stacktrace itself, or otherwise do something useful with the exception, such as retrying. Currently, the stacktrace is always logged by Hibernate, also if the client code recovers from the exception, which is a bit confusing when looking at the logs.
Also the fact that this particular exception is logged with severity ERROR is inappropriate. It's up to the client code to decide if it's an error.
I suggest the following change to AbstractFlushingEventListener:
Current code:
catch (HibernateException he) {
log.error("Could not synchronize database state with session", he);
throw he;
}
Suggested code:
catch (StaleObjectStateException e) {
log.warn("Could not synchronize database state with session", e.getMessage());
throw e;
}
catch (HibernateException he) {
log.error("Could not synchronize database state with session", he);
throw he;
}
--
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
16 years
[Hibernate-JIRA] Created: (ANN-771) @Formula Subqueries as a table is not work
by solonote (JIRA)
@Formula Subqueries as a table is not work
------------------------------------------
Key: ANN-771
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-771
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.4.0.GA
Environment: oralce10g hibernate3
Reporter: solonote
......
public class xxx{
......
@Formula("(select boxL.box_count from (select rownum box_count,l.id lid from dp.letter l where l.box_id = box_id) boxL where boxL.lid=id)")
private Integer boxCountId;
.......
}
Hibernate: ....(select boxL.box_count from (select rownum this_.box_count,l.id this_.lid from dp.letter l where l.box_id = this_.box_id) this_.boxL where boxL.lid=this_.id) as formula0_6_....
this sql sentence is wrong
"select boxL.box_count from (select rownum box_count,l.id lid from dp.letter l where l.box_id = this_.box_id)) boxL where boxL.lid=this_.id" <- this is correct.
please help me,thank you
--
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
16 years
[Hibernate-JIRA] Created: (HHH-3388) Problem mixing implicit and explicit joins - Ok in Hib2 not in Hib3
by Philippe Chaléat (JIRA)
Problem mixing implicit and explicit joins - Ok in Hib2 not in Hib3
-------------------------------------------------------------------
Key: HHH-3388
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3388
Project: Hibernate3
Issue Type: Bug
Reporter: Philippe Chaléat
Trying to migrate a rather large app from Hibernate 2.1 to Hibernate, we face a blocking problem. With Hibernate 3, some of our queries generate invalid SQL. I found in the forum that this problem has been noticed by someone else (but no answer) :
http://forum.hibernate.org/viewtopic.php?t=963196&highlight=join+ora00904
We manage to reproduce the problem with the following query. With Hibernate 2, mixing explicit and implicit joins produced an SQL query with all "theta style" joins at the end of the query. In Hibernate 3, ANSI and "theta style" are mixed, which Oracle doesn't like.
HBM:
select a.description, a.seller, b.item.description " +
"from org.hibernate.auction.AuctionItem a inner join a.bids b
[java] SQL:
[java] select
[java] auctionite0_.description as col_0_0_,
[java] auctionite0_.seller as col_1_0_,
[java] auctionite3_.description as col_2_0_,
[java] user2_.id as id2_,
[java] user2_.userName as userName2_,
[java] user2_."password" as password3_2_,
[java] user2_.email as email2_,
[java] user2_.firstName as firstName2_,
[java] user2_."initial" as initial6_2_,
[java] user2_.lastName as lastName2_
[java] from
[java] AuctionItem auctionite0_
[java] inner join
[java] Bid bids1_
[java] on auctionite0_.id=bids1_.item,
[java] AuctionItem auctionite3_
[java] inner join
[java] AuctionUser user2_
[java] on auctionite0_.seller=user2_.id
[java] where
[java] bids1_.item=auctionite3_.id
Erreur:
[java] org.hibernate.exception.SQLGrammarException: could not execute query
[java] at org.hibernate.exception.SQLStateConverter.convert(SQLStateCon
verter.java:67)
[java] at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExcep
tionHelper.java:43)
[java] at org.hibernate.loader.Loader.doList(Loader.java:2216)
[java] at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:
2104)
[java] at org.hibernate.loader.Loader.list(Loader.java:2099)
[java] at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:37
8)
[java] at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslato
rImpl.java:338)
[java] at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryP
lan.java:172)
[java] at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
[java] at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
[java] at org.hibernate.auction.Main.testOracleJoins(Main.java:359)
--
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
16 years