November 2011 - hibernate-issues - Jboss List Archives

[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

14 years, 4 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

14 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Commented: (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 commented on HHH-1123: ------------------------------------- Not sure what y'all are proposing as the fix here. Splitting the query is not a viable option. Yes it will work in some cases, but it will not work as a general solution. And as some have even mentioned on this thread, for some dialect its not just a restriction on the number of expressions allowed in an in-list; in some databases it is a restriction for the number of parameters allowed in the query overall. So just splitting the one-big-in-list into multiple smaller sized in lists OR'ed together is not going to address that. I am completely inclined to reject this, tbh... > 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

14 years, 4 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6869) SQLQuery setMaxResults with SQLServer 2008 or 2005 dialect causes a magic ROW_NUMBER() column to be inserted as the first column rather than the last

by Keith Mashinter (JIRA)

SQLQuery setMaxResults with SQLServer 2008 or 2005 dialect causes a magic ROW_NUMBER() column to be inserted as the first column rather than the last ----------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-6869 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6869 Project: Hibernate Core Issue Type: Bug Components: query-sql Affects Versions: 3.6.8 Environment: Hibernate 3.6.8, SQLServer 2008 Reporter: Keith Mashinter SQLQuery setMaxResults with SQLServer 2008 or 2005 dialect causes a magic ROW_NUMBER() column to be inserted as the first column rather than the last. This creates an unexpected shift in column order when setMaxResults() is used compared to when it is not, breaking the promise of least surprise from an API. NOT Using setMaxResults: SQLQuery qry = hs.createSQLQuery("select a,b,c from t"); qry.list(): a, b, c a1, b1, c1 But WITH Using setMaxResults the specified columns are shifted: SQLQuery qry = hs.createSQLQuery("select a,b,c from t"); qry.setMaxResults(1); qry.list(): __hibernate_row_nr__, a, b, c 1, a1, b1, c1 A compromise would be to put the __hibernate_row_nr__ last, although that still adds something not requested but it least it doesn't change the index of the columns that were requested. SQLQuery qry = hs.createSQLQuery("select a,b,c from t"); qry.setMaxResults(1); qry.list(): a, b, c, __hibernate_row_nr__ a1, b1, c1, 1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
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

14 years, 4 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-6862) Reuse cached entryArray of IdentityMap in StatefulPersistenceContext as much as possible

by Sanne Grinovero (JIRA)

Reuse cached entryArray of IdentityMap in StatefulPersistenceContext as much as possible ---------------------------------------------------------------------------------------- Key: HHH-6862 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6862 Project: Hibernate Core Issue Type: Improvement Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 4.0.0.next There are different options to iterate the containers of a StatefulPersistenceContext, and these iteration operations happen frequently. Usage of IdentityMap is able to cache cache the array it creates to provide a safe iteration during modifications, so I've collapsed all usage of the PersistenceContext to use less different iteration approaches, and this resulted in a small performance improvement and some code simplification. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-6068) JPA-specified default schema ignored for Hibernate sequences

by Laird Nelson (JIRA)

JPA-specified default schema ignored for Hibernate sequences ------------------------------------------------------------ Key: HHH-6068 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6068 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.2, 3.6.1, 3.6.0, 3.5.6 Reporter: Laird Nelson The <persistence-unit-defaults> element in a JPA 2.0-compliant orm.xml file lets you specify what you would like to have used as the default schema when none is specified elsewhere. Hibernate ignores this element when referring to its own internal sequence, "hibernate_sequence". I suspect it also ignores the default catalog element as well. The only workaround is to use the hibernate-specific hibernate.default_schema property. IMHO Hibernate should honor the JPA orm.xml value if it is present. -- 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

14 years, 4 months

5
14
0 / 0

[Hibernate-JIRA] Created: (HHH-6858) Minor performance improvements after hotspots analysis

by Sanne Grinovero (JIRA)

Minor performance improvements after hotspots analysis ------------------------------------------------------ Key: HHH-6858 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6858 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor 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

14 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6852) DB2 doesn't support exists in select

by Strong Liu (JIRA)

DB2 doesn't support exists in select ------------------------------------ Key: HHH-6852 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6852 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 4.0.0.CR6 Environment: DB2 Reporter: Strong Liu Assignee: Strong Liu it seems DB2 doesn't support "exists in select" (_org.hibernate.dialect.Dialect#supportsExistsInSelect_) which causes _org.hibernate.test.bidi.AuctionTest2#testLazy_ fail see http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fc... for more details -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6851) DB2 doesn't support NotNullUnique causes org.hibernate.test.annotations.uniqueconstraint.UniqueConstraintTest.testUniquenessConstraintWithSuperclassProperty fail

by Strong Liu (JIRA)

DB2 doesn't support NotNullUnique causes org.hibernate.test.annotations.uniqueconstraint.UniqueConstraintTest.testUniquenessConstraintWithSuperclassProperty fail ----------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-6851 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6851 Project: Hibernate Core Issue Type: Bug Components: testsuite Reporter: Strong Liu Assignee: Strong Liu Fix For: 4.0.0.next test _org.hibernate.test.annotations.uniqueconstraint.UniqueConstraintTest.testUniquenessConstraintWithSuperclassProperty_ checks Unique Constraint, but due to DB2 doesn't support NotNullUnique, and the unique constraint applied column in this test is nullable, so test fails -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
1
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 November 2011