April 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-7043) SQLServer2005Dialect should not use alias in the ORDER BY clause when paging

by George Gastaldi (JIRA)

SQLServer2005Dialect should not use alias in the ORDER BY clause when paging ---------------------------------------------------------------------------- Key: HHH-7043 URL: https://hibernate.onjira.com/browse/HHH-7043 Project: Hibernate ORM Issue Type: Bug Reporter: George Gastaldi Using alias in the OVER() statement is wrong, as http://msdn.microsoft.com/en-us/library/ms189461.aspx states that: {quote} When used in the context of a ranking window function, <ORDER BY Clause> can only refer to columns made available by the FROM clause. An integer cannot be specified to represent the position of the name or alias of a column in the select list. <ORDER BY Clause> cannot be used with aggregate window functions. {quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1107) WorkDoneOnEntitiesTest test times out on Sybase15

by Sanne Grinovero (JIRA)

WorkDoneOnEntitiesTest test times out on Sybase15 ------------------------------------------------- Key: HSEARCH-1107 URL: https://hibernate.onjira.com/browse/HSEARCH-1107 Project: Hibernate Search Issue Type: Task Affects Versions: 4.1.0.Final Reporter: Sanne Grinovero >From the matrix build on Jenkins, this is consistently happening on the jobs running sybase155 {quote} Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.423 sec Running org.hibernate.search.test.embedded.depth.WorkDoneOnEntitiesTest Build timed out (after 180 minutes). Marking the build as failed. Destroying 1 processes Destroying process.. {quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4030) Implement support for native recursive query functionality of popular DBMSes

by David Cracauer (JIRA)

Implement support for native recursive query functionality of popular DBMSes ---------------------------------------------------------------------------- Key: HHH-4030 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4030 Project: Hibernate Core Issue Type: New Feature Components: core, query-hql, query-sql Environment: Hibernate 3.3.2, MSSQL Reporter: David Cracauer We have a couple of areas in our system where need to load tree structures from our database. These trees can be very deep (often 20+ levels). SQL Server 2005 introduced Common Table Expressions, a kind of in-line view that can be used recursively. These allow us to quickly get a result set like this: id, label, parentId 1, foo, null 2, foo2, 1 3, foo3, 2 4, foo4, 2 5, foo5, 4 6, foo6, 1 >From a tree like this: [1, foo] | | -[2, foo2] | | - [3, foo3] | | - [4, foo4] | | - [5, foo5] |- [6, foo6] using a query like this (not tested): with MyCTE( id, label, parentId) as ( select n.id, n.label, n.parentid from Node n UNION ALL select c.id, c.label, c.parentId from MyCTE c inner join Node n on n.id=c.parentId) select * from MyCTE It happens many times more quickly than we've been able to load the graphs with Hibernate, even using batching etc. We've tried using hibernate's built in native sql support without success. The alias injection breaks the Common Table Expression definition ( with MyCTE ), as it is a view definition and doesn't allow for the 'id as id_276' syntax, rather requiring just a column name. I know that there are several other major DBMSes that support recursive querying now. Is there a way to have support for this functionality in hibernate core? -- 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

13 years, 11 months

3
2
0 / 0

[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

13 years, 11 months

2
7
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

13 years, 11 months

2
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

13 years, 11 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

13 years, 11 months

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

13 years, 11 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

13 years, 11 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-6848) The duration of hibernate merge rises quadratically with the amount of entities in a to be merged objectgraph

by Wim Ockerman (JIRA)

The duration of hibernate merge rises quadratically with the amount of entities in a to be merged objectgraph ------------------------------------------------------------------------------------------------------------- Key: HHH-6848 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6848 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 4.0.0.CR6, 3.6.8 Environment: Any Hibernate version, any database platform. Reporter: Wim Ockerman Attachments: HibernateMergeMeasurementBeforeAndAfterSolution.png, Sample_JProfiler_hotspot_research_in_a_merge_of_a_big_object_graph.png Tests with merging large objectgraphs showed quadratic rise of duration of the merge related to the object-graph size. >From a certain number of objects in the graph this becomes substantial. This limits hibernate scalability for larger object-graph usages. Analysis (based on 3.6.8 code branch): The merge algorithm of hibernate is a recursive objectgraph walking algorithm. During it's execution it builds up algorithm state information e.g. of merged entities to original objects in the input graph. The information is stored in the EventCache object in the *entityToCopyMap* member. ( org.hibernate.event.def.EventCache) At certain places in the merge algorithm the inverse relation as hold in the EventCache object is needed. see e.g. def.AbstractSaveEventListener.performSaveOrReplicate -> calling persister.getPropertyValuesToInsert(.., *getMergeMap()*,..) The getMergeMap() call calls through to the EventCache's invertMap method. In the implementation of invertMap() a new map is created on the spot and all the elements in the entityToCopyMap where put in, now as copy to entity direction. The call invertMap() happens more in a big detached graph wile merging, and also the size of the entityToCopyMap rises with the number of object already merged in the graph. Thus we have a quadratic relation between the total inverMap() execution time and the number of objects in a graph to be merged. JProfiler screenshot sample attached showing a high call count and high duration time on the invertMap method in a merge vs time it took for a flush of the merged object graph. The latter was unexpected, as the flush time is a good higher bound reference for an object graph operation. To solve this problem see proposed solution in pull request #208 of [hibernate-core] Performance Optimization of in memory merge algorithm. With the solution, the merge duration behaves more linear with respect to the size of the to be merged objectgraph. See attached plot of the original hibernate merge behaviour vs entities in a graph (redline) and the proposed solution's timeing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

4
15
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 April 2012