May 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-817) Make it possible to configure an alternative MergePolicy and MergeScheduler

by Sanne Grinovero (JIRA)

Make it possible to configure an alternative MergePolicy and MergeScheduler --------------------------------------------------------------------------- Key: HSEARCH-817 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-817 Project: Hibernate Search Issue Type: New Feature Reporter: Sanne Grinovero Priority: Minor Fix For: 4.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HHH-7301) Hibernate does not check value of the exclude-unlisted-classes element

by Dmitry Geraskov (JIRA)

Hibernate does not check value of the exclude-unlisted-classes element ---------------------------------------------------------------------- Key: HHH-7301 URL: https://hibernate.onjira.com/browse/HHH-7301 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 3.5.0-Final Reporter: Dmitry Geraskov Hibernate just check if this element present in persistence.xml and if present decide that the value is true. But it could be false. See PersistenceXmlLoader#parsePersistenceUnit(Element top) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7294) Envers manytomany Test BasicSametable fails on DB2 as DB2 does not support tinyint

by Madhumita Sadhukhan (JIRA)

Envers manytomany Test BasicSametable fails on DB2 as DB2 does not support tinyint ---------------------------------------------------------------------------------- Key: HHH-7294 URL: https://hibernate.onjira.com/browse/HHH-7294 Project: Hibernate ORM Issue Type: Bug Components: envers Affects Versions: 4.1.2 Reporter: Madhumita Sadhukhan Assignee: Strong Liu This testcase is failing while executing createquery: CREATE TABLE children_AUD(REV integer NOT NULL, REVEND integer, REVTYPE tinyint, parent_id integer, child1_id integer NULL, child2_id integer NULL) changing datatype for REVTYPE to smallint fixes this on DB2 https://issues.jboss.org/browse/JBPAPP-8898 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-7285) Using distinct in Criteria, using first- and maxResults, fails with SQLGrammarException when a colum in the distinct clause starts with 'from'

by Markus Horehled (JIRA)

Using distinct in Criteria, using first- and maxResults, fails with SQLGrammarException when a colum in the distinct clause starts with 'from' ---------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-7285 URL: https://hibernate.onjira.com/browse/HHH-7285 Project: Hibernate ORM Issue Type: Bug Components: query-criteria Affects Versions: 3.6.9 Environment: Spring 3.1.1, Hibernate 3.6.9, SQL Server 2008 Reporter: Markus Horehled Using Hibernate Criteria with setting first- and maxResults fails with an SQLGrammarException in SQLServer 2008 when one of the columns in the select distinct clause starts with a 'from', like fromDate. The original query would be something like: select distinct this_.Id as y0_, this_.FromDate as y1_ from ... whereas the query eventually issued by Hibernate is something like: WITH query AS (select ROW_NUMBER() OVER (order by this_.fromdate desc, this_.id asc) ... group by this_.id, this_.) SELECT * FROM query WHERE __hibernate_row_nr__ BETWEEN ? AND ? The fromDate column is apparently missing in the query's group by. Reason is found in the SQLServer2005Dialect class in getSelectFieldsWithoutAliases(StringBuilder sql), where a substring is constructed till the FROM (i.e. 'from') string. This should rather be 'from ', i.e. including a blank, since in that particular case the 'from' from the 'fromDate' column is being regarded as the end of the substring being constructed. Workaround is for example to not name any column being used in a distinct starting with 'from' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (OGM-168) Rename AssociationType to AssociationKind

by Emmanuel Bernard (JIRA)

Rename AssociationType to AssociationKind ----------------------------------------- Key: OGM-168 URL: https://hibernate.onjira.com/browse/OGM-168 Project: Hibernate OGM Issue Type: Improvement Components: core Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Priority: Minor Fix For: 4.0-next -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3961) SQLServerDialect, support nowait in LockMode.UPGRADE_NOWAIT

by Guenther Demetz (JIRA)

SQLServerDialect, support nowait in LockMode.UPGRADE_NOWAIT ------------------------------------------------------------ Key: HHH-3961 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3961 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.3.1 Environment: 3.3.1 GA , SQLServer2008 Reporter: Guenther Demetz Priority: Trivial The method SQLServerDialect#appendLockHint currently ignores the LockMode.UPGRADE_NOWAIT returning the same string as for LockMode.UPGRADE. public String appendLockHint(LockMode mode, String tableName) { if ( mode.greaterThan( LockMode.READ ) ) { // does this need holdlock also? : return tableName + " with (updlock, rowlock, holdlock)"; return tableName + " with (updlock, rowlock)"; } else { return tableName; } } As SQLServer supports the nowait option I propose the following improvement: public String appendLockHint(LockMode mode, String tableName) { if ( mode == LockMode.UPGRADE_NOWAIT) { return tableName + " with (updlock, rowlock, nowait)"; } else if ( mode.greaterThan( LockMode.READ ) ) { // does this need holdlock also? : return tableName + " with (updlock, rowlock, holdlock)"; return tableName + " with (updlock, rowlock)"; } else { return tableName; } } A test gave me a correct behaviour: if the concerning row is already locked, then after Lock request time out period exceeded following exception is thrown: org.hibernate.exception.SQLGrammarException: could not lock: [persistent.jpa.AssociationsClassPeer#1] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:90) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.dialect.lock.SelectLockingStrategy.lock(SelectLockingStrategy.java:115) at org.hibernate.persister.entity.AbstractEntityPersister.lock(AbstractEntityPersister.java:1361) at org.hibernate.event.def.AbstractLockUpgradeEventListener.upgradeLock(AbstractLockUpgradeEventListener.java:108) at org.hibernate.event.def.DefaultLockEventListener.onLock(DefaultLockEventListener.java:87) at org.hibernate.impl.SessionImpl.fireLock(SessionImpl.java:611) at org.hibernate.impl.SessionImpl.lock(SessionImpl.java:603) ... Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Lock request time out period exceeded. at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:196) at com.microsoft.sqlserver.jdbc.SQLServerResultSet$FetchBuffer.nextRow(SQLServerResultSet.java:4700) at com.microsoft.sqlserver.jdbc.SQLServerResultSet.fetchBufferNext(SQLServerResultSet.java:1683) at com.microsoft.sqlserver.jdbc.SQLServerResultSet.next(SQLServerResultSet.java:956) at com.p6spy.engine.spy.P6ResultSet.next(P6ResultSet.java:156) at com.p6spy.engine.logging.P6LogResultSet.next(P6LogResultSet.java:124) at com.mchange.v2.c3p0.impl.NewProxyResultSet.next(NewProxyResultSet.java:2859) at org.hibernate.dialect.lock.SelectLockingStrategy.lock(SelectLockingStrategy.java:97) ... 24 more -- 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, 8 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-7112) session.clear does not clear StatefulPersistenceContext.naturalIdResolutionCacheMap

by Guenther Demetz (JIRA)

session.clear does not clear StatefulPersistenceContext.naturalIdResolutionCacheMap ----------------------------------------------------------------------------------- Key: HHH-7112 URL: https://hibernate.onjira.com/browse/HHH-7112 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.0 Reporter: Guenther Demetz Priority: Minor According documentation session.clear clears the persistent context, so also StatefulPersistenceContext.naturalIdResolutionCacheMap should be cleared, otherwise we could run into memory retention problems. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-7299) Cannot scroll ScrollableResults outside of a transaction

by Ittay Dror (JIRA)

Cannot scroll ScrollableResults outside of a transaction -------------------------------------------------------- Key: HHH-7299 URL: https://hibernate.onjira.com/browse/HHH-7299 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.2 Reporter: Ittay Dror I have a repository class who is transactional but used by other classes that are not. One of its methods returns a ScrollableResults object. In 3.6.9 I was able to work with it (outside of the transaction), but in 4.1.2 I get an exception. Why should scrolling a query require a transaction? org.hibernate.HibernateException: proxy handle is no longer valid at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.errorIfInvalid(AbstractProxyHandler.java:63) ~[hibernate-core-4.1.2.jar:4.1.2] at org.hibernate.engine.jdbc.internal.proxy.AbstractResultSetProxyHandler.continueInvocation(AbstractResultSetProxyHandler.java:84) ~[hibernate-core-4.1.2.jar:4.1.2] at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(AbstractProxyHandler.java:81) ~[hibernate-core-4.1.2.jar:4.1.2] at $Proxy99.next(Unknown Source) ~[na:na] at org.hibernate.internal.ScrollableResultsImpl.next(ScrollableResultsImpl.java:116) ~[hibernate-core-4.1.2.jar:4.1.2] at com.alu.dal.util.HibernateScrollableIterator.advance(HibernateScrollableIterator.java:64) ~[classes/:na] at com.alu.dal.util.HibernateScrollableIterator.hasNext(HibernateScrollableIterator.java:41) ~[classes/:na] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7151) Like the query-API, also NaturalIdLoadAccess should provide method setFlushMode(FlushMode mode)

by Guenther Demetz (JIRA)

Like the query-API, also NaturalIdLoadAccess should provide method setFlushMode(FlushMode mode) ----------------------------------------------------------------------------------------------- Key: HHH-7151 URL: https://hibernate.onjira.com/browse/HHH-7151 Project: Hibernate ORM Issue Type: Improvement Components: core Affects Versions: 4.1.1 Environment: - Reporter: Guenther Demetz Implicit flushes in my opinion always should be, as widest as possible, under users control, this because unneccessary flushings often create serious implications, especially when working with long-time transactions. On long-time transactions the time-window between flush and final commit become big enough to cause lock-waits or/and lock-timeouts on concurrent transactions. With bugfix HHH-7094 the NaturalIdLoadAccess becomes pratically ununseable for our projects. Like on all Hibernate Query-Apis, the user should have the possibility to choose between variuos FlushModes. Example: (Simple)NaturalIdLoadAccess naturalIdAccess = session.by(Simple)NaturalId(MyEntity.class); naturalIdAccess.setFlushMode(FlushMode.AUTO); // flush if required naturalIdAccess.setFlushMode(FlushMode.COMMIT); // don't flush until commit time Object obj = naturalIdAccess.load(id); N.B.: I enabled the 'Requires Release Note' check-box, because this enhancement implies a behaviour change. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-7236) Natural-id : NullPointerException after persisting null String value, if using @NaturalIdCache

by Guenther Demetz (JIRA)

Natural-id : NullPointerException after persisting null String value, if using @NaturalIdCache ---------------------------------------------------------------------------------------------- Key: HHH-7236 URL: https://hibernate.onjira.com/browse/HHH-7236 Project: Hibernate ORM Issue Type: Bug Components: caching (L2), core Affects Versions: 4.1.2 Reporter: Guenther Demetz Following new matrix testmethod {code:title=org.hibernate.test.naturalid.mutable.cached.CachedMutableNaturalIdTest.java|borderStyle=solid} @Test public void testNaturalIdPersistNullValue() { Session session = openSession(); session.beginTransaction(); Another it = new Another(); it.setName(null); session.save( it ); session.getTransaction().commit(); // throws NPE session.close(); } {code} raises: java.lang.NullPointerException at org.hibernate.type.descriptor.java.AbstractTypeDescriptor.extractHashCode(AbstractTypeDescriptor.java:88) at org.hibernate.type.AbstractStandardBasicType.getHashCode(AbstractStandardBasicType.java:201) at org.hibernate.type.AbstractStandardBasicType.getHashCode(AbstractStandardBasicType.java:205) at org.hibernate.cache.spi.NaturalIdCacheKey.<init>(NaturalIdCacheKey.java:79) at org.hibernate.engine.internal.StatefulPersistenceContext$1.managedSharedCacheEntries(StatefulPersistenceContext.java:1801) at org.hibernate.engine.internal.StatefulPersistenceContext$1.manageSharedNaturalIdCrossReference(StatefulPersistenceContext.java:1792) at org.hibernate.action.internal.AbstractEntityInsertAction.handleNaturalIdPostSaveNotifications(AbstractEntityInsertAction.java:198) at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:130) at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:275) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:326) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1181) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:379) at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101) at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175) at org.hibernate.test.naturalid.mutable.cached.CachedMutableNaturalIdTest.testNaturalIdPersistNullValue(CachedMutableNaturalIdTest.java:127) ... N.B.: The exception does not happen without the @NaturalIdCache annotation Proposed solution: see pull request -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

2
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues May 2012