February 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5872) Methos generate in org.hibernate.id.enhanced.OptimizerFactory$PooledLoOptimizer classs is not synchronized

by Tchavdar Roussanov (JIRA)

Methos generate in org.hibernate.id.enhanced.OptimizerFactory$PooledLoOptimizer classs is not synchronized ----------------------------------------------------------------------------------------------------------- Key: HHH-5872 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5872 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.0, 3.6.0.CR2, 3.6.0.CR1, 3.5.6, 3.6.0.Beta4, 3.6.0.Beta3, 3.5.5, 3.6.0.Beta2, 3.6.0.Beta1, 3.5.4, 3.5.3, 3.5.2 Environment: Hibernate 3.5.6-Final, Oracle 11g, WebSphere 6.1 cluster Reporter: Tchavdar Roussanov Receiving multiple primary key constraint violation exceptions when using SequenceStyleGenerator with optimizer parameter set to pooled-lo. Looking into the source code I found that the generate mathod for the new PooledLoOptimizer is not synchronized. After switching to PooledOptimizer (which has synchronized generate method) every thing works fine. -- 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, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5303) @Cachable has no effect

by Paul Bakker (JIRA)

@Cachable has no effect ----------------------- Key: HHH-5303 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5303 Project: Hibernate Core Issue Type: Bug Components: caching (L2), entity-manager Affects Versions: 3.5.2 Environment: Tested on HSQL (included in testcase) and MySQL database Reporter: Paul Bakker The JPA 2.0 @Cachable annotation has no effect at all. Just putting @Cachable on a class is not enough to enable caching. You must also configure a concurrency strategy with either @Cache or a hibernate.ejb.classcache setting in persistence.xml. If those settings are in place, @Cacheble still has no effect. Entities are cached, but @Cachable(false) doesn't change this behavior. I included a Maven example project that tests this behavior. The project has two profiles to switch between Hibernate and EclipseLink: mvn -P hibernate clean test mvn -P eclipselink clean test -- 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, 11 months

3
12
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, 11 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, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5956) TS: Postgresql 8.2 - case sensitive identifiers fails BasicOperationsTest

by Ondra Žižka (JIRA)

TS: Postgresql 8.2 - case sensitive identifiers fails BasicOperationsTest ------------------------------------------------------------------------- Key: HHH-5956 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5956 Project: Hibernate Core Issue Type: Bug Components: testsuite Affects Versions: 3.6.2 Reporter: Ondra Žižka org.hibernate.test.annotations.dataTypes.BasicOperationsTest.testCreateAndDelete fails because it uses uppercase identifiers for querying metadata through JDBC. I suggest modifying the identifiers according to {{connection.getMetaData().storesLowerCaseIdentifiers()}} and friends. When this is fixed, the test fails because the SomeOtherEntity tries to store char containing zero byte: org.postgresql.util.PSQLException: Zero bytes may not occur in string parameters. at org.postgresql.core.v3.SimpleParameterList.toString(SimpleParameterList.java:163) Maybe that should be somewhere added to HHH-2942. -- 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, 11 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HV-318) Hibernate Validator doesn't compiles in OpenJDK 6

by Juraci Paixao Krohling (JIRA)

Hibernate Validator doesn't compiles in OpenJDK 6 ------------------------------------------------- Key: HV-318 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-318 Project: Hibernate Validator Issue Type: Bug Components: build Environment: RHEL5, OpenJDK6 Reporter: Juraci Paixao Krohling Assignee: Hardy Ferentschik /qa/hudson_ws/workspace/hibernate-validator-trunk/jdk/openjdk-local/label/RHEL5_any/trunk/hibernate-validator/src/test/java/org/hibernate/validator/util/TestUtil.java:[66,30] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>javax.validation.bootstrap.ProviderSpecificBootstrap<T> required: java.lang.Object -- 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, 11 months

3
12
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, 11 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, 11 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, 11 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5784) Save can fail when there is a transient entity reachable by multiple paths and at least one path does not cascade on save

by Strong Liu (JIRA)

Save can fail when there is a transient entity reachable by multiple paths and at least one path does not cascade on save ------------------------------------------------------------------------------------------------------------------------- Key: HHH-5784 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5784 Project: Hibernate Core Issue Type: Bug Components: core Reporter: Strong Liu This issue is the same as JBPAPP-915, but is for the save event. It may also affect persist and save-update events. The fix should be very similar to what was done for JBPAPP-915 and one fix may work for all of these types of events. This issue needs to be fixed to support JDK 1.6. Because the iteration order for HashSets and HashMaps is different for JDK 1.6, cascading operations to entities in a set may be saved in a different order, causing a cascade that worked in a previous version to fail with a TransientObjectException. See HHH-3229 for details. In addition, a note should go into the release notes that the change in order of cascades is a known issue. https://issues.jboss.org/browse/JBPAPP-2278 -- 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, 11 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2011