December 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-994) Update JBoss Logger to 3.1.0.CR2

by Sanne Grinovero (JIRA)

Update JBoss Logger to 3.1.0.CR2 -------------------------------- Key: HSEARCH-994 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-994 Project: Hibernate Search Issue Type: Task Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Trivial Fix For: 4.0.0.Final -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6867) test data overflow causes org.hibernate.test.cut.CompositeUserTypeTest.testCustomColumnReadAndWrite fails on DB2

by Strong Liu (JIRA)

test data overflow causes org.hibernate.test.cut.CompositeUserTypeTest.testCustomColumnReadAndWrite fails on DB2 ---------------------------------------------------------------------------------------------------------------- Key: HHH-6867 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6867 Project: Hibernate Core Issue Type: Bug Components: testsuite Reporter: Strong Liu Assignee: Strong Liu Priority: Minor Fix For: 4.0.0.next skip this test on db2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-6870) sysdate function in oracle dialect is a non argu and no parentheses function

by Strong Liu (JIRA)

sysdate function in oracle dialect is a non argu and no parentheses function ---------------------------------------------------------------------------- Key: HHH-6870 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6870 Project: Hibernate Core Issue Type: Bug Components: testsuite Reporter: Strong Liu Assignee: Strong Liu Priority: Minor Fix For: 4.0.0.next test _org.hibernate.test.legacy.SQLFunctionsTest#testDialectSQLFunctions_ fails on oracle due to the sql used in the test is using the function of _sysdate_ wrong. _sysdate_ is defined as NonArgu and hasNoParenthesesIfNoArguments, but in the test it used like this {code} select s.name, sysdate(), trunc(s.pay), round(s.pay) from Simple s {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
1
0 / 0

[Hibernate-JIRA] Issue Comment Edited: (HHH-1123) Cannot put more than 1000 elements in a InExpression

by Siddharth Shankar (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123?page=c... ] Siddharth Shankar edited comment on HHH-1123 at 12/1/11 12:24 AM: ------------------------------------------------------------------ I agree that there is no all purpose solution to this but what I also believe is that this is a general problem that should be addressed by a library code. A user can choose to use it or not to use it but the users should be provided with that choice. In addition to the use cases mentioned in the above comments, a user should be able to use the Restriction.in(String, Collection) without having to worry about the size of the collection (which he receives from another service) exceeding say n elements. This is for cases where the user expects the collection to be of size 5-100 usually but occassinally say 1000 but never 10000 (so the user validates that the size doesn't exceed 10000). The user code stays clean. The library can log a warning in cases where it considers that there are too many sub sets for in clause or if it forsees a problem or lack of support for a particular dialect instead of failing on all occassions(for n>1000). was (Author: siddharth.star): I agree that there is no all purpose solution to this but what I also believe is that this is a general problem that should be addressed by a library code. A user can choose to use it or not to use it but the users should be provided with that choice. In addition to the use cases mentioned in the above comments, a user should be able to use the Restriction.in(String, Collection) without having to worry about the size of the collection exceeding say n elements. This is for cases where the user expects the collection to be of size 5-100 usually but occassinally say 1000 but never 10000. The user code stays clean. The library can log a warning in cases where it considers that there are too many sub sets for in clause or if it forsees a problem or lack of support for a particular dialect instead of failing on all occassions(for n>1000). > Cannot put more than 1000 elements in a InExpression > ---------------------------------------------------- > > Key: HHH-1123 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.1 rc2, 3.2.0.alpha1 > Environment: Oracle 9i > Reporter: Alexis Seigneurin > Assignee: Strong Liu > Attachments: Animal.hbm.xml, hibernate-inexpression-oracle-3.2.patch, HQLHelper.java, LongInElementsTest.java, patch.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > The number of elements that we can put in a "in" expression is limited to a certain amount (1000 for Oracle, for instance). When creating a criteria query, the org.hibernate.criterion.InExpression class should split the expression into several smaller ones. > Attached is a patch which splits the expression by slices of 500 elements. For example, if we have 1001 elements to put in the "in" expression, the result would be : > (entity.field in (?, ?, ?...) or entity.field in (?, ?, ?...) or entity.field in (?)) > The surrounding parantheses are useful to avoid problems with other conditions (a "and" condition taking over the one of the "or" conditions). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1123) Cannot put more than 1000 elements in a InExpression

by Siddharth Shankar (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123?page=c... ] Siddharth Shankar commented on HHH-1123: ---------------------------------------- I agree that there is no all purpose solution to this but what I also believe is that this is a general problem that should be addressed by a library code. A user can choose to use it or not to use it but the users should be provided with that choice. In addition to the use cases mentioned in the above comments, a user should be able to use the Restriction.in(String, Collection) without having to worry about the size of the collection exceeding say n elements. This is for cases where the user expects the collection to be of size 5-100 usually but occassinally say 1000 but never 10000. The user code stays clean. The library can log a warning in cases where it considers that there are too many sub sets for in clause or if it forsees a problem or lack of support for a particular dialect instead of failing on all occassions(for n>1000). > Cannot put more than 1000 elements in a InExpression > ---------------------------------------------------- > > Key: HHH-1123 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.1 rc2, 3.2.0.alpha1 > Environment: Oracle 9i > Reporter: Alexis Seigneurin > Assignee: Strong Liu > Attachments: Animal.hbm.xml, hibernate-inexpression-oracle-3.2.patch, HQLHelper.java, LongInElementsTest.java, patch.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > The number of elements that we can put in a "in" expression is limited to a certain amount (1000 for Oracle, for instance). When creating a criteria query, the org.hibernate.criterion.InExpression class should split the expression into several smaller ones. > Attached is a patch which splits the expression by slices of 500 elements. For example, if we have 1001 elements to put in the "in" expression, the result would be : > (entity.field in (?, ?, ?...) or entity.field in (?, ?, ?...) or entity.field in (?)) > The surrounding parantheses are useful to avoid problems with other conditions (a "and" condition taking over the one of the "or" conditions). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1123) Cannot put more than 1000 elements in a InExpression

by Haavar Valeur (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123?page=c... ] Haavar Valeur commented on HHH-1123: ------------------------------------ I would really like some sort of solution for this. I see a lot of copy and paste code to break the parameters into subsets. I agree we should take a step back. Obviously I can't speak for everybody, but I don't think the most common problem is really people doing a select, with 1000+ parameters. I think if we looked closer at the real problems people are having, we might be other ways of solving them. I think the most common cases I've seen are that we needed the keys from a batch delete. In a particular case that's fresh in my mind, there was an external service that needed to be notified when records were purged. The way I ended solving it was breaking it into two queries, first I selected all the keys that was going to be deleted and then I issued a delete query with the set of keys as a parameter. I did not want to issue the delete query with the same criteria as the select in case the data changed between the select and delete. The result was a nice ticking timebomb, triggered when the purged set grew to a 1000 :). The cases I've dealt with could be solved if I could access the set of primary keys after an update or delete. > Cannot put more than 1000 elements in a InExpression > ---------------------------------------------------- > > Key: HHH-1123 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.1 rc2, 3.2.0.alpha1 > Environment: Oracle 9i > Reporter: Alexis Seigneurin > Assignee: Strong Liu > Attachments: Animal.hbm.xml, hibernate-inexpression-oracle-3.2.patch, HQLHelper.java, LongInElementsTest.java, patch.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > The number of elements that we can put in a "in" expression is limited to a certain amount (1000 for Oracle, for instance). When creating a criteria query, the org.hibernate.criterion.InExpression class should split the expression into several smaller ones. > Attached is a patch which splits the expression by slices of 500 elements. For example, if we have 1001 elements to put in the "in" expression, the result would be : > (entity.field in (?, ?, ?...) or entity.field in (?, ?, ?...) or entity.field in (?)) > The surrounding parantheses are useful to avoid problems with other conditions (a "and" condition taking over the one of the "or" conditions). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1870) org.hibernate.TransientObjectException: object references an unsaved transient

by Strong Liu (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1870?page=c... ] Strong Liu updated HHH-1870: ---------------------------- Fix Version/s: (was: 4.0.0.CR7) 4.0.0.next > org.hibernate.TransientObjectException: object references an unsaved transient > ------------------------------------------------------------------------------- > > Key: HHH-1870 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1870 > Project: Hibernate Core > Issue Type: Bug > Environment: Hibernate 3.2.0 RC 2 from SVN tunk 2006/06/30 > Reporter: Sergey Vladimirov > Assignee: Gail Badner > Fix For: 4.0.0.next > > Attachments: manytoonelazy.zip, patch.txt > > > JUnit test case shows strange error on commit(): > Session session = sessionFactory.openSession(); > Transaction transaction = session.beginTransaction(); > BeanB beanB = new BeanB(); > beanB.setId(1); > session.save(beanB); > beanB = (BeanB) session.load(BeanB.class, 1); > BeanA beanA = new BeanA(); > beanA.setId(2); > beanA.setParent((BeanB) session.load(BeanB.class, 1)); > session.save(beanA); > transaction.commit(); > session.close(); > org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: ru.arptek.arpsite.data.manytoonelazy.BeanA.parent -> ru.arptek.arpsite.data.manytoonelazy.BeanB > at org.hibernate.engine.CascadingAction$9.noCascade(CascadingAction.java:273) > at org.hibernate.engine.Cascade.cascade(Cascade.java:257) > at org.hibernate.event.def.AbstractFlushingEventListener.cascadeOnFlush(AbstractFlushingEventListener.java:131) > at org.hibernate.event.def.AbstractFlushingEventListener.prepareEntityFlushes(AbstractFlushingEventListener.java:121) > at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:65) > at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26) > at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) > at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) > at org.hibernate.transaction.JTATransaction.commit(JTATransaction.java:135) > at ru.arptek.arpsite.data.manytoonelazy.TestWithoutCache.testFind(TestWithoutCache.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > Temporary patch included. May be it is brokes other issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6865) PessimisticLockException should be thrown when pessimistic read and write locking strategies fail

by Gail Badner (JIRA)

PessimisticLockException should be thrown when pessimistic read and write locking strategies fail ------------------------------------------------------------------------------------------------- Key: HHH-6865 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6865 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 4.0.0.CR6 Reporter: Gail Badner Assignee: Gail Badner Fix For: 4.0.0.next In some cases, when a pessimistic read/write locking strategy fails with SQLException, Hibernate converts the SQLException to a org.hibernate.JDBCException, but does not wrap the JDBCException in a org.hibernate.PessimisticLockException. This affects: PessimisticReadSelectLockingStrategy.lock(...) PessimisticReadUpdateLockingStrategy.lock(...) PessimisticWriteSelectLockingStrategy.lock(...) PessimisticWriteUpdateLockingStrategy.lock(...) These methods specifically catch SQLException, convert it to a org.hibernate.JDBCException, and wrap in a org.hibernate.PessimisticLockException. If Hibernate does the conversion immediately when the statement fails and throws JDBCException, then lock(...) does not have the opportunity to catch it and wrap it in a org.hibernate.PessimisticLockException. This issue is reproduced in LockTest failures on Oracle. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-6868) Lazily initialize HashMap in LockOptions

by Sanne Grinovero (JIRA)

Lazily initialize HashMap in LockOptions ---------------------------------------- Key: HHH-6868 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6868 Project: Hibernate Core Issue Type: Improvement Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.0.0.next these options might not be used at all, but take lots of memory. Profiling memory, this HashMap instances are the bigger objects of all, they might not take much memory as LockOptions is usually short loved, but it generates a lot of allocations and GC work anyway. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Issue Comment Edited: (HHH-1123) Cannot put more than 1000 elements in a InExpression

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123?page=c... ] Steve Ebersole edited comment on HHH-1123 at 11/30/11 9:09 PM: --------------------------------------------------------------- I think we might need to step back here and ask ourselves about the validity of queries with 1000+ expression long IN lists and 2000+ overall parameters... But as to the specifics of splitting it up into multiple queries and then I guess merging results back in memory, that for sure will not work. What about: {code} select ... from ... where column_a in (x, ..., x1000) and column_b in (y, ..., y1000) {code} was (Author: steve): I think we might need to step back here and ask ourselves about the validity of queries with 1000 expression long IN lists and 2000 overall parameters... But as to the specifics of splitting it up into multiple queries and then I guess merging results back in memory, that for sure will not work. What about: {code} select ... from ... where column_a in (x, ..., x1000) and column_b in (y, ..., y1000) {code} > Cannot put more than 1000 elements in a InExpression > ---------------------------------------------------- > > Key: HHH-1123 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.1 rc2, 3.2.0.alpha1 > Environment: Oracle 9i > Reporter: Alexis Seigneurin > Assignee: Strong Liu > Attachments: Animal.hbm.xml, hibernate-inexpression-oracle-3.2.patch, HQLHelper.java, LongInElementsTest.java, patch.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > The number of elements that we can put in a "in" expression is limited to a certain amount (1000 for Oracle, for instance). When creating a criteria query, the org.hibernate.criterion.InExpression class should split the expression into several smaller ones. > Attached is a patch which splits the expression by slices of 500 elements. For example, if we have 1001 elements to put in the "in" expression, the result would be : > (entity.field in (?, ?, ?...) or entity.field in (?, ?, ?...) or entity.field in (?)) > The surrounding parantheses are useful to avoid problems with other conditions (a "and" condition taking over the one of the "or" conditions). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues December 2011