May 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5053) Duplicate primary keys when using the SEQUENCE strategy due to underlying sequence not being updated when the SequenceGenerator's allocatedSize is greater than 1

by atomicknight (JIRA)

Duplicate primary keys when using the SEQUENCE strategy due to underlying sequence not being updated when the SequenceGenerator's allocatedSize is greater than 1 ----------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-5053 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5053 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0-CR-2 Environment: Hibernate 3.5.0-CR-2 PostgreSQL 8.4.1 (JDBC driver 8.4-701 JDBC4) Glassfish v3 (build 74.2) JDK 1.6.0_18 Reporter: atomicknight Attachments: jpa-test.war, table1.sql When the SequenceGenerator's allocatedSize is greater than 1, the underlying sequence associated with the table doesn't ever seem to be updated by Hibernate except on application startup. The test case uses an allocatedSize of 3, corresponding to an increment value of 3 in the underlying sequence. Here's how to use the test case (requires EJB 3.1): 1) Set up the database using the attached SQL dump, then load the application 2) Access the test page via http://localhost:8080/jpa-test/test. You should see a page with the word "Done!" 3) Undeploy and redeploy the application 4) Access the test page again. You should encounter an error page indicating that the transaction was aborted. Here's what I observed at the database level while following the above steps: 1) Sequence is created with a start value of 1 and increment value of 3. 2) Hibernate increments the sequence to 4. The application then inserts rows with IDs 12-31. 3) No change - the sequence still has a value of 4. 4) Hibernate increments the sequence to 7. The application attempts to insert a row with ID 21, but fails because the ID was already used in step 2. Setting the SequenceGenerator's allocatedSize to 1 as well as changing the increment value of the sequence to 1 gives the correct behavior. -- 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

15 years, 11 months

4
7
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-324) @DynamicBoost(BoostStrategy.class)

by Emmanuel Bernard (JIRA)

@DynamicBoost(BoostStrategy.class) ---------------------------------- Key: HSEARCH-324 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-324 Project: Hibernate Search Issue Type: New Feature Components: mapping Reporter: Emmanuel Bernard Fix For: 3.1.1, 3.2.0 This sounds like an interesting feature. We could do something very similar to the new AnalyzerDiscriminator approach. The use case is explained http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=78... Need some analysis before the jump We can do that in 3.1.1, but no hard pressure. -- 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

15 years, 11 months

4
9
0 / 0

[Hibernate-JIRA] Created: (HHH-5207) Unexpected exception occurs during refresh of a transient immutable business object.

by James Norton (JIRA)

Unexpected exception occurs during refresh of a transient immutable business object. ------------------------------------------------------------------------------------ Key: HHH-5207 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5207 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1, 3.5.0-Final Environment: Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production, Hibernate 3.5.1, Spring 3.0.2, Struts 1.3.10, J2SE 1.6.0_14 Reporter: James Norton Attachments: TestCase.zip As mentioned in the Hibernate Forums (_[Cannot make an immutable entity modifiable|https://forums.hibernate.org/viewtopic.php?f=1&t=1003756]_), I am dealing with an issue brought to my attention wherein a detached transient business object is being refreshed by the session and returns an exception. The exception(_See Below_) is thrown from within the DefaultRefreshEventListener's onRefresh method at the end of processing just prior to returning the refreshed object. ---- {{{code:title=The Exception} java.lang.IllegalStateException: Cannot make an immutable entity modifiable. at org.hibernate.engine.EntityEntry.setReadOnly(EntityEntry.java:314) at org.hibernate.engine.StatefulPersistenceContext.setEntityReadOnly(StatefulPersistenceContext.java:1388) at org.hibernate.engine.StatefulPersistenceContext.setReadOnly(StatefulPersistenceContext.java:1365) at org.hibernate.impl.SessionImpl.setReadOnly(SessionImpl.java:1982) at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:155) at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:62) at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:1108) at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:1088) at bug.BugReport.testRefreshTransientImmutable(BugReport.java:136) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:168) at org.hibernate.junit.functional.FunctionalTestCase.runTest(FunctionalTestCase.java:125) at junit.framework.TestCase.runBare(TestCase.java:134) at org.hibernate.junit.UnitTestCase.runBare(UnitTestCase.java:63) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:243) at org.hibernate.junit.functional.FunctionalTestClassTestSuite.runTest(FunctionalTestClassTestSuite.java:115) at junit.framework.TestSuite.run(TestSuite.java:238) at org.hibernate.junit.functional.FunctionalTestClassTestSuite.run(FunctionalTestClassTestSuite.java:84) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) {code}}} ---- This problem showed up during an update from Hibernate libraries 3.3.2. The issue was proven not to exist in the previous version through the attached test case. It is mine and my coworkers opinion that the issue lies with the DefaultRefreshEventListener attempting to set the read only state of the refreshed object _back_ to the state that it was in prior to refreshing. Being that the object is detached from the current session, and therefore viewed as transient, the previous state of the object cannot be ascertained and the listener tries to set the read only to source default. ---- {{{code:title=DefaultRefreshEventListener lines 152 - 156 \\\\ onRefresh(RefreshEvent event, Map refreshedAlready)} // Keep the same read-only/modifiable setting for the entity that it had before refreshing; // If it was transient, then set it to the default for the source. if ( result != null ) { source.setReadOnly( result, ( e == null ? source.isDefaultReadOnly() : e.isReadOnly() ) ); } {code}}} ---- While this appears to be a fairly straightforward procedure, the object being refreshed is immutable. With the object being transient, the persistence context does not have an entry for the object and the _source_ tries to {{*setReadOnly*}} to {{source.isDefaultReadOnly()}}. This results in the session trying to set an immutable object's state to writable. -- 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

15 years, 11 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HHH-4065) Incorrect SQL is used for HQL if the number of values for a filter collection parameter is changed

by Nicklas Nordborg (JIRA)

Incorrect SQL is used for HQL if the number of values for a filter collection parameter is changed -------------------------------------------------------------------------------------------------- Key: HHH-4065 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4065 Project: Hibernate Core Issue Type: Bug Components: query-hql Affects Versions: 3.3.2 Environment: Hibernate 3.3.2 Reporter: Nicklas Nordborg Attachments: trace.txt I think that maybe the fix for HHH-530 has introduced a problem with filters that has a collection-type parameter. If the number of parameters in that collection changes during the lifetime of a SessionFactory the SQL that is used becomes incorrect and either has too many or too few parameter placeholders (eg. '?') in the SQL. There was no problem in Hibernate 3.3.1. A typical error message is: java.sql.SQLException: Parameter index out of bounds. 2 is not between valid values of 1 and 1 Below is some pseudo-code that shows what happens when the number of values in a collection is increased from 1 to 2. The 'memberOf' is a simple filter on the `id` column: `id` IN (:items) String hql = "select n from NewsData n"; List idList = new ArrayList(); idList.add(1); Session s = .... // create new session s.enableFilter("memberOf").setParameterList("items", idList); s.createQuery(hql).list(); // SQL: select .... `News` newsdata0_ where newsdata0_.`id` IN (?) s.close(); idList.add(2); s = ... // create new session s.enableFilter("memberOf").setParameterList("items", idList); s.createQuery(hql).list(); // <--- error here with 3.3.2 but works with 3.3.1 // SQL (3.3.2): select .... `News` newsdata0_ where newsdata0_.`id` IN (?) // SQL (3.3.1): select .... `News` newsdata0_ where newsdata0_.`id` IN (?, ?) I am attaching a file with TRACE-level output from both Hibernate 3.3.2 and 3.3.1. The relevant difference seems to be that in Hibernate 3.3.2 the query plan is cached with: [SQL_TOKEN] SqlFragment: 'newsdata0_.`id` IN (?)' but in Hibernate 3.3.1 with: [SQL_TOKEN] SqlFragment: 'newsdata0_.`id` IN (:memberOf.items)' -- 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

15 years, 11 months

5
14
0 / 0

[Hibernate-JIRA] Created: (HHH-5211) no need to create a schema first when run this test org.hibernate.test.sql.hand.custom.db2.DB2CustomSQLTest

by Strong Liu (JIRA)

no need to create a schema first when run this test org.hibernate.test.sql.hand.custom.db2.DB2CustomSQLTest ----------------------------------------------------------------------------------------------------------- Key: HHH-5211 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5211 Project: Hibernate Core Issue Type: Bug Components: testsuite Reporter: Strong Liu Fix For: 3.5.2, 3.6 creating a schema in DB2 is not something that applications should do -- 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

15 years, 11 months

1
3
0 / 0

[Hibernate-JIRA] Commented: (HBX-633) Reverse engineered VERSION columns cause ClassCastException

by Max Rydahl Andersen (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-633?page=co... ] Max Rydahl Andersen commented on HBX-633: ----------------------------------------- as written earlier: " you can work around it via a custom reveng strategy that just returns false for useColumnForOptimisticLock." > Reverse engineered VERSION columns cause ClassCastException > ----------------------------------------------------------- > > Key: HBX-633 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-633 > Project: Hibernate Tools > Issue Type: Bug > Affects Versions: 3.1beta4 > Environment: Oracle 8i, ojdbc14.jar > Reporter: Gabor Kincses > > Exception in thread "main" java.lang.ClassCastException: org.hibernate.type.BigDecimalType > at org.hibernate.tuple.PropertyFactory.buildVersionProperty(PropertyFactory.java:83) > at org.hibernate.tuple.EntityMetamodel.<init>(EntityMetamodel.java:157) > at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:412) > at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:108) > at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55) > at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:216) > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1176) > at com.paypal.bdo.test.Hibernate101.main(Hibernate101.java:37) > I guess the code tries to cast the type to VersionType. -- 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

15 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5203) JDBCException thrown during schema export (or hbm2dll) should include sql

by Rupesh Kumar (JIRA)

JDBCException thrown during schema export (or hbm2dll) should include sql ------------------------------------------------------------------------- Key: HHH-5203 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5203 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1 Reporter: Rupesh Kumar The JDBCException thrown during Schema export (SchemaExport.create(), SchemaExport.importScript(), SchemaUpdate.execute()) should include the SQL string. -- 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

15 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1501) insert long string (more than 32700) fails on derby

by Jeff Schnitzer (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1501?page=c... ] Jeff Schnitzer commented on HHH-1501: ------------------------------------- This certainly sounds reasonable; I will keep an eye on HHH-2578. Thanks for the continued development! > insert long string (more than 32700) fails on derby > --------------------------------------------------- > > Key: HHH-1501 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1501 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.5.0-Beta-2 > Environment: Derby 10 > Reporter: Sergey Vladimirov > Priority: Trivial > > http://issues.apache.org/jira/browse/DERBY-102 > VARCHAR maximum length 32 672 > LONG VARCHAR maximum length 32 700 > CLOB maximum length 2 147 483 647 > BLOB maximum length 2 147 483 647 > this issue can be reproduced by org.hibernate.test.lob.TextTest (in 3.5 beta1,2) with change org.hibernate.test.lob.LongStringTest.LONG_STRING_SIZE > 32700 -- 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

15 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5199) Formula should use aliases in order by

by Stephane Epardaud (JIRA)

Formula should use aliases in order by -------------------------------------- Key: HHH-5199 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5199 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Reporter: Stephane Epardaud Same bug as HB-958 but filed for hibernate 3. Not every database supports formulas or functions in WHERE clauses, and while we would love to get rid of them, it's not always realistic. It should not be hard to reuse the alias generated for formulas from the SELECT clause. Reminder: - This does not work on every DB: {noformat} SELECT length(id) FROM t ORDER BY length(id); {noformat} - This works on several DBs: {noformat} SELECT length(id) AS l FROM t ORDER BY l; {noformat} If there are any DBs where hibernate is broken because of that, it should be a Dialect feature. In the original bug report, Gavin mentioned trivial workarounds. It would be helpful to show them in the bug report too, since they might not be obvious (I've no clue for instance). -- 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

15 years, 11 months

2
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-1853) CREATE SCHEMA inside database-object need to execute before tables are created

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1853?page=c... ] Steve Ebersole commented on HHH-1853: ------------------------------------- BTW I do see the benefit of something like <database>. If someone wanted to take that one and attach a patch I'd be willing to apply it (if its well done of course) > CREATE SCHEMA inside database-object need to execute before tables are created > ------------------------------------------------------------------------------ > > Key: HHH-1853 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1853 > Project: Hibernate Core > Issue Type: Improvement > Affects Versions: 3.1.3 > Environment: hsqldb 1.8.0 > Reporter: Mattias Jiderhamn > Priority: Minor > Attachments: create-schema.patch, create-schema2.patch > > > In order to have Hibernate create database schemas for hsqldb, you have to insert a <database-object> in your mapping file (http://forums.hibernate.org/viewtopic.php?p=2305138). Problem is, all the database-object statements are executed after the tables are created, so tables in non-default schemas will not be created. To get around this, you have to first use Configuration.generateSchemaCreationScript() to get the schemas, and then Configuration.generateSchemaUpdateScript() to get the tables inside the schemas. > (This is a bit problematic when using Springs LocalSessionFactoryBean) -- 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

15 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues May 2010