November 2011 - hibernate-issues - Jboss List Archives

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

by Alexander Rytov (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123?page=c... ] Alexander Rytov commented on HHH-1123: -------------------------------------- Please update fix version for this issue. > 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, 6 months

1
0
0 / 0

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

by Koloskov Alexey (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123?page=c... ] Koloskov Alexey commented on HHH-1123: -------------------------------------- Is there a plan date for fix this issue? > 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, 6 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6816) Upgrade to jboss-logging 3.1.0.CR1

by Steve Ebersole (JIRA)

Upgrade to jboss-logging 3.1.0.CR1 ---------------------------------- Key: HHH-6816 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6816 Project: Hibernate Core Issue Type: Task Components: build, core Affects Versions: 4.0.0.CR5 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.next >From David: {{quote}} OK folks. I've pushed out jboss-logging 3.1.0.CR1 and jboss-logging-tools 1.0.0.CR4. Here's what you need to do. 0. Update your dep versions (obviously) 1. Add the following switch to your annotation processing step (or to javac if it's combined): -AloggingVersion=3.0 2. Build your artifacts against jboss-logging 3.1.0.CR1. 3. When you publish the POMs for artifacts built this way, you may specify jboss-logging 3.0.0.GA as the required version, and it will be compatible with such. Basically what you're doing with the -AloggingVersion=3.0 flag is generating larger classes in exchange for backwards compatibility. If you develop other frameworks which are not expected to be supported on AS 7.0 (for example), you do not need this flag (logging version 3.1 is required in this case). {{quote}} We will continue to export 3.1 as the outgoing dependency. AS can manage swapping that to 3.0 for the 7.0 builds. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6798) Upgrade to Hibernate Commons Annotations GA once it's released

by Emmanuel Bernard (JIRA)

Upgrade to Hibernate Commons Annotations GA once it's released -------------------------------------------------------------- Key: HHH-6798 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6798 Project: Hibernate Core Issue Type: Task Components: core Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Fix For: 4.0.0.next -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HCANN-42) Make sure project build with JDK 7

by Emmanuel Bernard (JIRA)

Make sure project build with JDK 7 ---------------------------------- Key: HCANN-42 URL: http://opensource.atlassian.com/projects/hibernate/browse/HCANN-42 Project: Hibernate Commons Annotations Issue Type: Task Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard 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, 6 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HCANN-41) Upgrade JBoss Logging and align version numbers

by Emmanuel Bernard (JIRA)

Upgrade JBoss Logging and align version numbers ----------------------------------------------- Key: HCANN-41 URL: http://opensource.atlassian.com/projects/hibernate/browse/HCANN-41 Project: Hibernate Commons Annotations Issue Type: Task Affects Versions: 4.0.0.CR2 Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard 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, 6 months

1
1
0 / 0

[Hibernate-JIRA] Created: (OGM-108) Will not compile and run tests using JDK7

by rikki molecatert (JIRA)

Will not compile and run tests using JDK7 ----------------------------------------- Key: OGM-108 URL: http://opensource.atlassian.com/projects/hibernate/browse/OGM-108 Project: Hibernate OGM Issue Type: Bug Components: build, core Environment: New install of Ubuntu 11.10, maven2, openjdk-7-jdk, openjdk-6-jdk. Reporter: rikki molecatert Priority: Minor Attachments: output.txt Three methods are missing from three classes. They are in abstract parent classes according to the stack trace and are required to be overridden. The output from maven is attached. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
5
0 / 0

[Hibernate-JIRA] Commented: (HHH-6700) mysql test failures

by Gail Badner (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6700?page=c... ] Gail Badner commented on HHH-6700: ---------------------------------- Strong, I noticed that you changed 6000 to 60000 in 11f83b0373a2f02f9880098d8adc5fb027a774dc. Was something else going wrong that prompted that change? > mysql test failures > ------------------- > > Key: HHH-6700 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6700 > Project: Hibernate Core > Issue Type: Sub-task > Environment: MySql 51 > Reporter: Strong Liu > > org.hibernate.test.hql.ASTParserLoadingTest.testJPAQLQualifiedIdentificationVariablesControl > org.hibernate.test.hql.ASTParserLoadingTest.testPaginationWithPolymorphicQuery > org.hibernate.test.hql.ASTParserLoadingTest.testImplicitPolymorphism > org.hibernate.test.hql.ASTParserLoadingTest.testCachedJoinedAndJoinFetchedManyToOne > org.hibernate.test.hql.ASTParserLoadingTest.testCachedJoinedAndJoinFetchedOneToMany > org.hibernate.test.id.uuid.sqlrep.sqlbinary.UUIDBinaryTest.testUsage > org.hibernate.test.id.uuid.strategy.CustomStrategyTest.testUsage > org.hibernate.test.instrument.runtime.JavassistInstrumentationTest.testLazy > org.hibernate.test.instrument.runtime.JavassistInstrumentationTest.testCustomColumnReadAndWrite > org.hibernate.test.instrument.runtime.JavassistInstrumentationTest.testFetchAll > org.hibernate.test.instrument.runtime.JavassistInstrumentationTest.testLazyManyToOne > org.hibernate.test.instrument.runtime.JavassistInstrumentationTest.testPropertyInitialized > org.hibernate.test.querycache.QueryCacheTest.testCaseInsensitiveComparison > org.hibernate.test.sql.hand.query.NativeSQLQueriesTest.testTextTypeInSQLQuery > org.hibernate.test.sql.hand.query.NativeSQLQueriesTest.testImageTypeInSQLQuery > org.hibernate.test.tm.CMTTest.testConcurrentCachedDirtyQueries > org.hibernate.test.sql.hand.custom.mysql.MySQLCustomSQLTest.testScalarStoredProcedure > org.hibernate.test.sql.hand.custom.mysql.MySQLCustomSQLTest.testParameterHandling > org.hibernate.test.sql.hand.custom.mysql.MySQLCustomSQLTest.testEntityStoredProcedure > org.hibernate.test.sql.hand.custom.mysql.MySQLCustomSQLTest.testHandSQL -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-6700) mysql test failures

by Gail Badner (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6700?page=c... ] Gail Badner commented on HHH-6700: ---------------------------------- I found out why org.hibernate.test.tm.CMTTest.testConcurrentCachedDirtyQueries is getting an unexpected second-level cache hit. org.hibernate.testing.cache.BaseRegion.getTimeout() returns Timestamper.ONE_MS * 600000. Timestamper.ONE_MS is 4095. The product is 2457000000, which overflows the int return value, so a negative timeout is returned. As a result, the update timestamp ends up being before the cached query result timestamp. Hibernate assumes (erroneously) that the cached query results are up-to-date. The cache hit that caused the test failure happened when resolving the IDs returned by the cached results. Changing BaseRegion.getTimeout() to return Timestamper.ONE_MS * 60000 gets past that assertion, but later ones fail. I'm working my way through those. > mysql test failures > ------------------- > > Key: HHH-6700 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6700 > Project: Hibernate Core > Issue Type: Sub-task > Environment: MySql 51 > Reporter: Strong Liu > > org.hibernate.test.hql.ASTParserLoadingTest.testJPAQLQualifiedIdentificationVariablesControl > org.hibernate.test.hql.ASTParserLoadingTest.testPaginationWithPolymorphicQuery > org.hibernate.test.hql.ASTParserLoadingTest.testImplicitPolymorphism > org.hibernate.test.hql.ASTParserLoadingTest.testCachedJoinedAndJoinFetchedManyToOne > org.hibernate.test.hql.ASTParserLoadingTest.testCachedJoinedAndJoinFetchedOneToMany > org.hibernate.test.id.uuid.sqlrep.sqlbinary.UUIDBinaryTest.testUsage > org.hibernate.test.id.uuid.strategy.CustomStrategyTest.testUsage > org.hibernate.test.instrument.runtime.JavassistInstrumentationTest.testLazy > org.hibernate.test.instrument.runtime.JavassistInstrumentationTest.testCustomColumnReadAndWrite > org.hibernate.test.instrument.runtime.JavassistInstrumentationTest.testFetchAll > org.hibernate.test.instrument.runtime.JavassistInstrumentationTest.testLazyManyToOne > org.hibernate.test.instrument.runtime.JavassistInstrumentationTest.testPropertyInitialized > org.hibernate.test.querycache.QueryCacheTest.testCaseInsensitiveComparison > org.hibernate.test.sql.hand.query.NativeSQLQueriesTest.testTextTypeInSQLQuery > org.hibernate.test.sql.hand.query.NativeSQLQueriesTest.testImageTypeInSQLQuery > org.hibernate.test.tm.CMTTest.testConcurrentCachedDirtyQueries > org.hibernate.test.sql.hand.custom.mysql.MySQLCustomSQLTest.testScalarStoredProcedure > org.hibernate.test.sql.hand.custom.mysql.MySQLCustomSQLTest.testParameterHandling > org.hibernate.test.sql.hand.custom.mysql.MySQLCustomSQLTest.testEntityStoredProcedure > org.hibernate.test.sql.hand.custom.mysql.MySQLCustomSQLTest.testHandSQL -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6814) Adding item to persistent set causes hibernate to individually load each set item

by Tim Heys (JIRA)

Adding item to persistent set causes hibernate to individually load each set item --------------------------------------------------------------------------------- Key: HHH-6814 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6814 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.7 Environment: Hibernate 3.6.7 Core with PostrgreSQL 8.2.18 Reporter: Tim Heys When adding an item to a Persistent Set hibernate loads each item of the set individually even if the set has already been loaded. My code: @OneToMany(fetch = FetchType.LAZY, targetEntity = Item.class, mappedBy = "parent", cascade = CascadeType.ALL, orphanRemoval = true) @Cascade(org.hibernate.annotations.CascadeType.ALL) @BatchSize(size = 20) @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) @IndexedEmbedded(prefix = "item") @Valid public Set<Item> getItems() { return items; } Calling "obj.getItems().add(newItem);", Hibernate loads EVERY item in the Set with it's own query: select eitem0_.id as id5_0_, eitem0_.parent_id as parent_id5_0_, eitem0_.field1 as field13_5_0_, eitem0_.field2 as field24_5_0_, eitem0_.field3 as field35 as_5_0_ from items eitem0_ where eitem0_.id=? I suppose it gets the IDs from the previous query when it loaded all the items: select eitem0_.parent_id as parent4_3_1_, eitem0_.id as id1_, eitem0_.id as id5_0_, eitem0_.field1 as field15_0_, eitem0_.field2 as field23_5_0_, eitem0_.parent_id as parent4_5_0_, eitem0_.field3 as field35_5_0_ from items eitem0_ where eitem0_.parent_id=? This makes for a very inefficient add to Set operation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 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 November 2011