October 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3684) Sybase - Setting FetchMode.JOIN fails if there are 3 or more joins and at least one join involves a union

by Gail Badner (JIRA)

Sybase - Setting FetchMode.JOIN fails if there are 3 or more joins and at least one join involves a union --------------------------------------------------------------------------------------------------------- Key: HHH-3684 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3684 Project: Hibernate Core Issue Type: Bug Components: core Reporter: Gail Badner Assignee: Gail Badner This is reproduced by UnionSubclassTest.testUnionSubclassFetchMode().. This may be due to a bug in Sybase. A similar problem is discussed here: http://www.forumtopics.com/busobj/viewtopic.php?p=442226&sid=40bd96248c52... For the unit test mentioned above, changing: select ... from ( select ... from humans union select ... from employees ) this_ inner join locations location2_ on this_.location=location2_.id left outer join ( select ... from employees union select ... from humans union select ... from aliens ) beings3_ on location2_.id=beings3_.location : to: select ... from ( select ... from humans union select ... from employees ) this_ inner join (locations location2_ left outer join ( select ... from employees union select ... from humans union select ... from aliens ) beings3_ on location2_.id=beings3_.location) : on this_.location=location2_.id fixes the problem. This changer is similar to what is documented for a "right-nested outer join" at http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc32300.150.... -- 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

12 years, 7 months

3
11
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-56) Updating a collection does not reindex

by Emmanuel Bernard (JIRA)

Updating a collection does not reindex -------------------------------------- Key: HSEARCH-56 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-56 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.0.0.beta1 Reporter: Emmanuel Bernard -- 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

12 years, 7 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3220) Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions

by Dan Bisalputra (JIRA)

Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions ----------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3220 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3220 Project: Hibernate3 Issue Type: Patch Components: core Affects Versions: 3.2.6 Environment: Hibernate 3.2.6, Apache Derby on Mac OSX & PC Reporter: Dan Bisalputra Priority: Minor When performing a query in a stateless session, the query loads objects in a two-phase process in which a temporary persistence context is populated with empty objects in the first phase, then the objects' member data are read from the database in the second phase. If one of the objects contains an association or a collection, it performs a recursive call to the session's get() method. The get() method clears the temporary persistence context, so if the parent object contains any other associations to be read in the second phase, Hibernate throws an assertion because they are not found in the persistence context. This patch solves the problem by only clearing the persistence context when the recursion ends. It passes all the unit tests for our application, but I have not tested it with any of the Hibernate unit tests. -- 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

12 years, 7 months

8
17
0 / 0

[Hibernate-JIRA] Created: (ANN-720) cant bind a child using mappedby relating to a parent attribute(polymorphism)

by Nino Martinez (JIRA)

cant bind a child using mappedby relating to a parent attribute(polymorphism) ----------------------------------------------------------------------------- Key: ANN-720 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-720 Project: Hibernate Annotations Issue Type: Bug Components: binder Affects Versions: 3.3.1.GA Environment: osx 10.4, java 1.5 Reporter: Nino Martinez Attachments: JPA101.zip This is pseudo class hieracy @Entity @Inheritance(strategy = InheritanceType.JOINED) Mammal { @ManyToOne Person owner; } @Entity Cat extends Mammal Person{ @Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN) @OneToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REMOVE }, mappedBy = "owner") private List<Cat> cats = new ArrayList<Cat>(); } it gives the error mission property: javax.persistence.PersistenceException: org.hibernate.AnnotationException: mappedBy reference an unknown target entity property: Cat.owner in Person.cats This is the related thread on hibernate forum: http://forum.hibernate.org/viewtopic.php?p=2380570#2380570 I can confirm that the same example does work when using OpenJPA as a provider. Please see attached project for reference. Please do not hesitate me if you have questions. -- 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

12 years, 7 months

7
13
0 / 0

[Hibernate-JIRA] Created: (HHH-3637) Union in where doesn't works for Sybase, need to evict test case

by Juraci Paixao Krohling (JIRA)

Union in where doesn't works for Sybase, need to evict test case ---------------------------------------------------------------- Key: HHH-3637 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3637 Project: Hibernate Core Issue Type: Improvement Components: testsuite Environment: Sybase ASE 15.0.2 Reporter: Juraci Paixao Krohling Assignee: Juraci Paixao Krohling It seems that Sybase doesn't supports UNION inside WHERE clauses, causing the test DynamicFilterTest#testSqlSyntaxOfFiltersWithUnions to fail. The scenario for this test case is not described in the documentation, but I would expect it to work: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.... The query is: select category0_.CAT_ID as CAT1_6_, category0_.name as name6_, category0_.eff_start_dt as eff3_6_, category0_.eff_end_dt as eff4_6_ from CATEGORY category0_ where 'abc' in ( select d.reg from department d where ( d.dept_id=123 ) union select p.name from sales_person p ) If executed only the queries from inside the where clause (the two selects with union), it works as expected. Also, if removed the union and one of the queries inside the where, it works as expected. So, the problem happens only when using union inside a where clause. For now, I'd suggest to evict this test for Sybase. -- 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

12 years, 7 months

5
10
0 / 0

[Hibernate-JIRA] Created: (HHH-2447) Connection leak if logAndClearWarnings throws

by Jeppe N. Madsen (JIRA)

Connection leak if logAndClearWarnings throws ---------------------------------------------- Key: HHH-2447 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2447 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.3, 3.2.2 Environment: Database product name : DB2/NT Database product version : SQL08025 JDBC driver name : IBM DB2 JDBC Universal Driver Architecture Hibernate 3.1.3 (seems to exist in 3.2.2 as well) JDBC driver version : 2.9.31 Reporter: Jeppe N. Madsen Priority: Minor In ConnectionManager.closeConnection, logAndClearWarnings is called before connection.close() is called. If this call throws an exception, the connection is never closed. We have observed that DB2 sometimes throws an Error because the SQLWarning chain is wrong: [14-02-07 11:36:30:889 CET] 10b0b533 WebGroup E SRVE0026E: [Servlet Error]-[SQLWarning chain holds value that is not a SQLWarning]: java.lang.Error: SQLWarning chain holds value that is not a SQLWarning at java.sql.SQLWarning.getNextWarning(SQLWarning.java:109) at org.hibernate.util.JDBCExceptionReporter.logWarnings(JDBCExceptionReporter.java:50) at org.hibernate.util.JDBCExceptionReporter.logWarnings(JDBCExceptionReporter.java:33) at org.hibernate.util.JDBCExceptionReporter.logAndClearWarnings(JDBCExceptionReporter.java:22) at org.hibernate.jdbc.ConnectionManager.closeConnection(ConnectionManager.java:443) at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:379) at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:318) at org.hibernate.impl.SessionImpl.close(SessionImpl.java:293) -- 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

12 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4015) one-to-one: foreign key: save Problem

by Sandeep Vaid (JIRA)

one-to-one: foreign key: save Problem ------------------------------------- Key: HHH-4015 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4015 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.2.6 Reporter: Sandeep Vaid Priority: Critical I have one-to-one relationship between class A and class B <class name="A" table="TEMPA" > <id name="aaId" type="string" column="AID" length="10"> <generator class="assigned"></generator> </id> <one-to-one name="b" class="B" constrained="true" outer-join="false" cascade="save-update" /> </class> <class name="B" table="TEMPB" lazy="true"> <id name="baId" type="string" column="BID" length="10"> <generator class="foreign"> <param name="property">a</param> </generator> </id> <one-to-one name="a" class="A" /> </class> Problem 1: When i try to save A, it fires : insert into HBLEARN1.TEMPB (BID) values ('1') and throws error : The insert or update value of the FOREIGN KEY "TEMPB.CC1246876555824" is not equal to any value of the parent key of the parent table. SQLSTATE=23503 Why it is first trying to save 'B' instead of 'A' first ? Problem 2: With this mapping, if i set <property name="hibernate.hbm2ddl.auto">create</property> in hibernate.cfg.xml, It generates TEMPA whose aaId is the foreign key referencing TEMPB. This is also incorrect.. -- 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

12 years, 7 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2075) many-to-one in a properties element causes strange PropertyValueException on flush

by Josh Moore (JIRA)

many-to-one in a properties element causes strange PropertyValueException on flush ---------------------------------------------------------------------------------- Key: HHH-2075 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2075 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr4 Environment: HSQLDB Hibernate r10478 Reporter: Josh Moore Attachments: exception.txt, log.txt, properties.zip Full test directory zip (org/hibernate/test/properties) attached. But to summarize, the following test will fail on flush after a simple merge. The exception thrown says that Pixels.sizeC is null -- though it's clearly set in the test case. <code> Image i = new Image(); Pixels p = new Pixels(); p.setSizeC(new Integer(2)); p.setImage(i); // This calls i.getPixels().add(p) // i.setPixels(null); // This makes it work. Session s = openSession(); Transaction t = s.beginTransaction(); // s.merge(i); // This makes it work. p = (Pixels) s.merge(p); // This fails with the exception below. t.commit(); s.close(); </code> The properties element in question is: <code> <properties name="defaultPixelsTag"> <property name="defaultPixels" type="java.lang.Boolean"/> <many-to-one name="image" class="Image" column="image" not-null="true" unique="false" insert="true" update="true" cascade="lock,merge,persist,replicate,refresh,save-update" /> </properties> </code> The reverse side is: <code> <set name="pixels" lazy="true" inverse="true" cascade="lock,merge,persist,replicate,refresh,save-update"> <key column="image" not-null="false"/> <one-to-many class="Pixels"/> </set> </code> -- 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

12 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3102) Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate()

by Paul Cowan (JIRA)

Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate() -------------------------------------------------------------------------------- Key: HHH-3102 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3102 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.4.sp1 Reporter: Paul Cowan Priority: Minor Attachments: HibernateKeyPoolTest.java Hi all, Not 100% sure if you'd call this a 'bug' as I'm not sure if the correct behaviour is actually specified anywhere. It's certainly oddly inconsistent though. Please find attached a standalone test case (requires HSQLDB on the classpath; amend setUp() if you need to use something else) which models a parent-child mapping between 'Mouth' (1) and 'Teeth' (many). The Mouth -> Teeth relationship is bidirectional, with CascadeType.ALL on the single-valued end. Both Mouth and Tooth use a @GenericGenerator, which simply allocates integers from a static keypool. A mouth with one tooth is created, saveOrUpdate()d, session is flushed, a new tooth is added, mouth is saveOrUpdate()d again, and session is again flushed. The debug output is as follows: *** After creation Mouth (id=null) has teeth [canine(id=null)] *** Save Mouth (id=1) has teeth [canine(id=2)] *** Flush Hibernate: insert into Mouth (id) values (?) Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?) Mouth (id=1) has teeth [canine(id=2)] *** Add new Mouth (id=1) has teeth [canine(id=2), molar(id=null)] *** Save again Mouth (id=1) has teeth [canine(id=2), molar(id=null)] *** Flush again Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?) Mouth (id=1) has teeth [canine(id=2), molar(id=3)] As you can see, when initially created the IDs for the mouth and tooth are both null (obviously correct). The saveOrUpdate() on the Mouth object then generates identifier values, even though no DB write has been done yet (the .flush()). So far, so good. However, when a NEW transient Tooth instance ("molar") is added to the Mouth, and saveOrUpdate() is called once more, the id generator is not invoked, UNTIL such time as the session is flushed. While I guess it's fine for an object in the 'persistent' state not to actually have an identifier until flush-time (e.g. when using DB-side IDENTITY-type generation), it just seems inconsistent that with a @GenericGenerator the behaviour would vary depending on whether the PARENT object was already persistent or not. There are some obvious workarounds (e.g. flush the session upon saving, or save the child entity first independently) but I thought I'd clarify if this behaviour is by design or not and suggest that this be made consistent. -- 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

12 years, 7 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2166) Long "in" lists in queries results in a Java stack overflow exception.

by Philip R. "Pib" Burns (JIRA)

Long "in" lists in queries results in a Java stack overflow exception. ---------------------------------------------------------------------- Key: HHH-2166 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2166 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Environment: Hibernate 3.2.0.cr3 through 3.2.0.ga (at least). Any standard deployment of Sun's JVM on Windows, Linux, or Mac OS X (and presumably other platforms like Solaris) Reporter: Philip R. "Pib" Burns Attachments: NodeTraverser.java With Hibernate 320ga a long "in" list can result in a stack overflow error during the parsing stage. For example, a query element like where x in (:x) or a manually constructed where x in (1,2,3 .....) can generate a stack overflow if the number of elements referenced by x exceeds a number dependent upon the amount of available stack space. For many JVMs, the limit is between 9,000 and 10,000 assuming a relatively empty stack at the point of query execution. We have applications which occasionally use lists several times this size. The stack overflow occurs in org.hibernate.hql.ast.util.NodeTraverser which uses a recursive algorithm to walk a parse tree. Long "in" lists generate a subtree of depth about equal to the number of elements in the list. A sufficiently long list results in a stack overflow when NodeTraverser's internal method visitDepthFirst calls itself too many times. The solution is to replace the recursive tree walking strategy with an iterative one that does not use up stack space. I am attaching the source for a replacement version of . NodeTraverser which implements the iterative tree walking method. -- 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

12 years, 7 months

11
41
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2009