March 2010 - hibernate-issues - Jboss List Archives

[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: (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-3718) call to id getter initializes proxy when using AccessType( "field" )

by Paul Lorenz (JIRA)

call to id getter initializes proxy when using AccessType( "field" ) -------------------------------------------------------------------- Key: HHH-3718 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3718 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: hibernate 3.3.1, hibernate annotations 3.4.0, running on windows, linux and solaris, using sybase 15 Reporter: Paul Lorenz Calling getter for id when using AccessType( "field" ) causes proxy initialization. In org.hibernate.proxy.proxy.pojo.BasicLazyInitializer there is the code else if ( isUninitialized() && method.equals(getIdentifierMethod) ) { return getIdentifier(); } However, when using field access, the getIdentifierMethod will be null. I fixed this for us by changing DirectPropertyAccessor by adding a Method attribute to the DirectGetter inner class, and looking up the appropriate getter in the constructor. As far as I can tell, getMethod is only used in two places. In the above case, to the get the identity getter and in PojoComponentTupilizer.isMethodOf. This doesn't seem to break anything. I don't know if this is a clean solution, seems a little hacky to me, however, it would be great if the issue could be fixed somehow. public static final class DirectGetter implements Getter { private final transient Field field; private final Class clazz; private final String name; private Method method; DirectGetter(Field field, Class clazz, String name) { this.field = field; this.clazz = clazz; this.name = name; try { BeanInfo beanInfo = Introspector.getBeanInfo( clazz ); PropertyDescriptor[] pdArray = beanInfo.getPropertyDescriptors(); if ( pdArray != null ) { for (PropertyDescriptor pd : pdArray ) { if ( pd.getName().equals( name ) ) { this.method = pd.getReadMethod(); } } } } catch ( Exception e ) { // ignore } } public Object get(Object target) throws HibernateException { try { return field.get(target); } catch (Exception e) { throw new PropertyAccessException(e, "could not get a field value by reflection", false, clazz, name); } } public Object getForInsert(Object target, Map mergeMap, SessionImplementor session) { return get( target ); } public Method getMethod() { return method; } public String getMethodName() { return method == null ? null : method.getName(); } public Class getReturnType() { return field.getType(); } Object readResolve() { return new DirectGetter( getField(clazz, name), clazz, name ); } public String toString() { return "DirectGetter(" + clazz.getName() + '.' + name + ')'; } } -- 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

10
18
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-295) Generate the "right" FilterKey instance even on parameterized filters

by Emmanuel Bernard (JIRA)

Generate the "right" FilterKey instance even on parameterized filters --------------------------------------------------------------------- Key: HSEARCH-295 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-295 Project: Hibernate Search Issue Type: New Feature Components: engine Reporter: Emmanuel Bernard Priority: Minor Rules around object equality are the most tricky. Not sure we can do a good job at it. -- 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
4
0 / 0

[Hibernate-JIRA] Created: (BVAL-108) Implement a simpe performance test harness for Bean Validation

by Hardy Ferentschik (JIRA)

Implement a simpe performance test harness for Bean Validation -------------------------------------------------------------- Key: BVAL-108 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-108 Project: Bean Validation Issue Type: Task Components: ri-general Reporter: Hardy Ferentschik JPerf could for example be used. -- 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

1
14
0 / 0

[Hibernate-JIRA] Created: (HHH-2614) Blob Length Set to 255 By Default With Derby DB

by Sean Sylvis (JIRA)

Blob Length Set to 255 By Default With Derby DB ----------------------------------------------- Key: HHH-2614 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2614 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.3 Environment: Apache Derby 10.2.2, Java 1.6.0 Reporter: Sean Sylvis When the (Hibernate) type "blob" is used in an object mapping file and a length is not specified, Hibernate converts this type as "blob (255)" to the Apache Derby database table definition. (This seems to be the same as the conversion behavior of a Java String to "varchar (255).") The same behavior results when using a CustomType that returns a Java SQL Types.BLOB. This is not the behavior I expected. Hibernate converts the same type as simply "blob" (which has a maximum length of 65535 bytes when no length is specified) when using MySQL version 5.0 (http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html). Furthermore, the Derby specification (http://db.apache.org/derby/docs/10.2/ref/rrefblob.html) states that a blob type without a length value will default to a length of 2M-1 bytes. I could not find a length specification for the Java SQL Blob type (http://java.sun.com/javase/6/docs/api/), but the current default length does seem to conform to other Hibernate type standards. That is, if a length is not specified, the length defaults to the maximum length defined for that type by the database. -- 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

9
13
0 / 0

[Hibernate-JIRA] Created: (HHH-3240) In Derby field type 'text' is converted to CLOB(255)

by Aleksander Rozman (JIRA)

In Derby field type 'text' is converted to CLOB(255) ---------------------------------------------------- Key: HHH-3240 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3240 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.1 Environment: Hibernate 3.1, Derby 10.3.2.1 Reporter: Aleksander Rozman Priority: Blocker When using type 'text' this is incorectly converted to CLOB(255). Derby has several long var char types which could be used instead, but instead it's defaulted to clob(255). I have taken a look at source from 3.1 and 3.2.6 (latest) and this code is still the same... I think that just little fix in DerbyDialect would be enough... I would try this myself but I am currently lacking time and resources. I hope this will be taken care of as soon as it gets... -- 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, 12 months

7
25
0 / 0

[Hibernate-JIRA] Created: (HHH-5043) Incorrect handling of hibernate.default_schema in SchemaUpdate

by Vladimir Klyushnikov (JIRA)

Incorrect handling of hibernate.default_schema in SchemaUpdate -------------------------------------------------------------- Key: HHH-5043 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5043 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.5.0-CR-2 Environment: Hibernate Core 3.5.0-CR-2, Oracle 10.2 Reporter: Vladimir Klyushnikov Attachments: cfg.patch While HHH-735 fixes default_schema handling in general, it still has a bug. When SchemaUpdate reads foreign keys metainfo is doesn't honor default_schema and default_catalog settings. The fix is simple and patch is attached. -- 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, 12 months

3
7
0 / 0

[Hibernate-JIRA] Created: (ANN-728) @NaturalId doesn't work with @Embeddable/@Embedded

by Kenny MacLeod (JIRA)

@NaturalId doesn't work with @Embeddable/@Embedded -------------------------------------------------- Key: ANN-728 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-728 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.1.GA Reporter: Kenny MacLeod Attachments: BugTestCase.java If I try to annotate an @Entity's field with @NaturalId, and that field happens to be @Embedded or @Embeddable, then hibernate barfs with org.hibernate.MappingException: Unable to find logical column name from physical name component in table BugTestCase$MyEntity at org.hibernate.cfg.Mappings.getLogicalColumnName(Mappings.java:514) at org.hibernate.cfg.IndexOrUniqueKeySecondPass.doSecondPass(IndexOrUniqueKeySecondPass.java:61) at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1136) at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:324) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292) at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:859) See attached unit test as a demonstration. Surely this is not an exotic scenario? Tested with Hibernate Core 3.2.6-GA -- 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

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2085) org.hibernate.event.def.DefaultLoadEventListener logs exception at info level

by Don Smith (JIRA)

org.hibernate.event.def.DefaultLoadEventListener logs exception at info level ----------------------------------------------------------------------------- Key: HHH-2085 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2085 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr2 Environment: Hibernate 3.2.0.cr2, MySQL 4.0.18 Reporter: Don Smith Priority: Minor Prior to schema generation, accessing a persistent object throws an exception, as expected. The org.hibernate.event.def.DefaultLoadEventListener logs the exception at the info level, which just adds noise to the application console, and prevents application exception handling (in my case it's valid if the table doesn't exist, so I just want to catch the exception and continue). This log statement should be removed, or moved to a debug or trace level, so it won't show up in normal execution. Code, from line 94 of org.hibernate.event.def.DefaultLoadEventListener: catch(HibernateException e) { log.info("Error performing load command", e); throw e; } -- 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

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