June 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5302) Hibernate is returning proxy objects even if no matching row is found on the database

by Ovidiu Guse (JIRA)

Hibernate is returning proxy objects even if no matching row is found on the database ------------------------------------------------------------------------------------- Key: HHH-5302 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5302 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.5.1, 3.3.2 Reporter: Ovidiu Guse Hi guys, I have an issue with Hibernate and I don't know for sure if it is me doing something wrong or this is a bug / "feature". Maybe someone has stepped into the same problem and there is a way out. Supposing I have a table 'Persons' with the normal structure: ID, first_name and last_name, and the following records: ID FIRST_NAME LAST_NAME 1 Jon Doe 2 Jane Doe On my persistence service implementation (Spring based), I have a method like: public Person findById(final Serializable id) { return getHibernateTemplate().load(Person.class, id); } Now, everything is working fine if I'm passing to this method one of the valid IDs 1 or 2. The problem appears when I'm passing for example -1 or 3, which do not exist at the time of the query in the table. The result I'm getting is a proxy object with all fields set to null, when in fact I was expecting the null value as result. And of course, my code implements specific behavior depending on that operation result, for example if the result is null, will throw an exception triggering some other execution paths. First I guessed it was because of the javassist bytecode provider used by Hibernate, but it turns out the same thing is happening with the cglib provider. This issue has appeared when using Hibernate 3.2 GA, but is still there in Hibernate 3.5.1 Final. The only (odd) difference between the two Hibernate version is that in Hibernate 3.2 the proxy object returns the invalid id value used for search (e.g. person.getId() returns -1 or 3), while Hibernate 3.5.1 will throw an exception about "No row with given identifier was found ..." when trying to read the object's ID value. I have searched the Hibernate forums and came across these two links which are not pointing to a valid solution: http://opensource.atlassian.com/projects/hibernate/browse/EJB-167 http://opensource.atlassian.com/projects/hibernate/browse/HHH-1714 For now the ugly solution was to implement the toString() method on every domain object model and after each search like this to log the result object. This will generate an exception if the proxy result is not mapping a valid database row. Is there a better way to handle this issue, or has somebody a solution in disabling this "beautiful" Hibernate behavior? Thanks, Ovi -- 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
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3045) Duplicated column aliases in scalar query

by Anderson Souza (JIRA)

Duplicated column aliases in scalar query ----------------------------------------- Key: HHH-3045 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3045 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: Hibernate 3.2.4SP1, 3.2.5GA Oracle 10g Reporter: Anderson Souza Priority: Critical Attachments: ddl-tables.sql, dominio.zip The HQL bellow works fine, but when I add a call to a funcion in the select clause the SQL generated has duplicated aliases and it generate error on query execution, because the query is paginated. {code} select a from Area a inner join fetch a.horarioPadrao left outer join fetch a.horarioTemporario as hrtemp {code} The SQL generated for this query is: {code} select * from ( select area0_.cod_local as cod1_15_0_, horarioare1_.cod_area as cod1_6_1_, horarioare2_.cod_area as cod1_7_2_, area0_.des_local as des2_15_0_, area0_.sig_local as sig3_15_0_, area0_.flg_extinto as flg4_15_0_, horarioare1_.hr_hora_ini as hr2_6_1_, horarioare1_.hr_hora_fim as hr3_6_1_, horarioare1_.flg_fim_semana as flg4_6_1_, horarioare2_.hr_hora_ini as hr2_7_2_, horarioare2_.hr_hora_fim as hr3_7_2_, horarioare2_.flg_fim_semana as flg4_7_2_, horarioare2_.dat_ini_vigencia as dat5_7_2_, horarioare2_.dat_fim_vigencia as dat6_7_2_ from esq_fp.tb_local area0_ inner join tb_horario_local_padrao horarioare1_ on area0_.cod_local=horarioare1_.cod_area left outer join tb_horario_local_temporario horarioare2_ on area0_.cod_local=horarioare2_.cod_area where 1=1 order by area0_.sig_local ) where rownum <= ? {code} The scalar HQL query that generate duplicated column names is: {code} select a, count(*) from Area a inner join fetch a.horarioPadrao left outer join fetch a.horarioTemporario as hrtemp {code} The SQL generated is: {code} select * from ( select area0_.cod_local as col_0_0_, count(*) as col_1_0_, horarioare1_.cod_area as cod1_6_1_, horarioare2_.cod_area as cod1_7_2_, area0_.cod_local as cod1_15_0_, horarioare1_.cod_area as cod1_6_1_, horarioare2_.cod_area as cod1_7_2_, area0_.des_local as des2_15_0_, area0_.sig_local as sig3_15_0_, area0_.flg_extinto as flg4_15_0_, horarioare1_.hr_hora_ini as hr2_6_1_, horarioare1_.hr_hora_fim as hr3_6_1_, horarioare1_.flg_fim_semana as flg4_6_1_, horarioare2_.hr_hora_ini as hr2_7_2_, horarioare2_.hr_hora_fim as hr3_7_2_, horarioare2_.flg_fim_semana as flg4_7_2_, horarioare2_.dat_ini_vigencia as dat5_7_2_, horarioare2_.dat_fim_vigencia as dat6_7_2_ from esq_fp.tb_local area0_ inner join tb_horario_local_padrao horarioare1_ on area0_.cod_local=horarioare1_.cod_area left outer join tb_horario_local_temporario horarioare2_ on area0_.cod_local=horarioare2_.cod_area where 1=1 order by area0_.sig_local ) where rownum <= ? {code} As you can see the aliases cod1_6_1_ and cod1_7_2_ are repeated and this repetition breaks the paginated query, beacause the main query appears in the from clause. The HBM's and classes are 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, 11 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-4053) Incorrect SQL with substring for Firebird

by yeti the foot (JIRA)

Incorrect SQL with substring for Firebird ----------------------------------------- Key: HHH-4053 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4053 Project: Hibernate Core Issue Type: Bug Components: query-sql Affects Versions: 3.3.1 Reporter: yeti the foot HQL query substring function generate incorrect SQL query for Firebird. In Firebird SQL query with substring has follow syntax: substring(str from 1 for 3). Generated ин Hibernate query looks like: substring(str, 1, 3). -- 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
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5290) Enhance getter/setter method search logic in org.hibernate.bytecode.javassist.BulkAccessorFactory

by Kirill Klenski (JIRA)

Enhance getter/setter method search logic in org.hibernate.bytecode.javassist.BulkAccessorFactory ------------------------------------------------------------------------------------------------- Key: HHH-5290 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5290 Project: Hibernate Core Issue Type: Task Components: core Environment: 3.3.1-GA Reporter: Kirill Klenski Priority: Minor Attachments: BulkAccessorFactory.java.patch org.hibernate.bytecode.javassist.BulkAccessorFactory.findAccessors(...) searches for accessor methods in the optimized entity class only. This means that the methods from the superclasses are not visible during BulkAccessor creation unless overridden by child classes. By enhancing the algorithm to search down the inheritance tree we could avoid creation of redundant methods which increase the code verbosity a lot. In our case almost all the entities are inherited from the base classes having the common entity properties defined, so the reflection optimization does not work for any of them until we override the inherited methods in all the child classes. Proposed org.hibernate.bytecode.javassist.BulkAccessorFactory patch 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, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5289) Remove unnecessary security checks in property accessors

by Kirill Klenski (JIRA)

Remove unnecessary security checks in property accessors -------------------------------------------------------- Key: HHH-5289 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5289 Project: Hibernate Core Issue Type: Task Components: core Environment: 3.3.1 GA Reporter: Kirill Klenski Priority: Minor Setting Method.setAccessible() and Field.setAccessible() to true helps to avoid security checks. Currently it is executed only for non-public class members. Code example from DirectPropertyAccessor: if ( !ReflectHelper.isPublic(theClass, method) ) { method.setAccessible(true); } Using this call for public members as well will increase the reflection call performance. -- 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
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5293) Envers doesn't adequately support the PrimaryKeyJoinColumn

by Ken Lowther (JIRA)

Envers doesn't adequately support the PrimaryKeyJoinColumn ---------------------------------------------------------- Key: HHH-5293 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5293 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.2.4.sp1 Environment: Windows XP, JBoss 4.2.2, Envers 1.2.1.GA, Oracle 10g Reporter: Ken Lowther Attachments: PrimaryKeyJoinColumn1.jar A parent/child entity pair are joined by the @PrimaryKeyJoinColumn annotation in the child class. When inserting an audit row into the child entity's corresponding audit table, the child entity uses the name of the parent's primary key instead of its own primary key. The value is the same, but the column names may be different. The attached test case uses Widget (parent) and RedWidget (child) to illustrate this issue. Here is the generated SQL: insert into WIDGET_AUD (REVTYPE, WIDGET_DESC, WIDGET_ID, REV) values (?, ?, ?, ?) Hibernate: insert into RED_WIDGET_AUD (RED_WIDGET_PROPERTY, WIDGET_ID, REV) values (?, ?, ?) The following exception is returned when an insert of the RedWidget committed: WARN logExceptions, SQL Error: 904, SQLState: 42000 ERROR logExceptions, ORA-00904: "WIDGET_ID": invalid identifier ERROR performExecutions, Could not synchronize database state with session org.hibernate.exception.SQLGrammarException: could not insert: [org.jboss.envers.test.entities.RedWidgetEntity_AUD] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:90) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2285) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2678) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:79) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1028) at org.hibernate.envers.synchronization.AuditSync.beforeCompletion(AuditSync.java:167) at org.hibernate.transaction.JDBCTransaction.notifyLocalSynchsBeforeTransactionCompletion(JDBCTransaction.java:274) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:140) at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:54) at org.jboss.envers.test.PrimaryKeyJoinColumnTest.initData(PrimaryKeyJoinColumnTest.java:29) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580) at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:398) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:145) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:82) at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:167) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:104) at org.testng.TestRunner.runWorkers(TestRunner.java:712) at org.testng.TestRunner.privateRun(TestRunner.java:582) at org.testng.TestRunner.run(TestRunner.java:477) at org.testng.SuiteRunner.runTest(SuiteRunner.java:324) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:319) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:292) at org.testng.SuiteRunner.run(SuiteRunner.java:198) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:823) at org.testng.TestNG.runSuitesLocally(TestNG.java:790) at org.testng.TestNG.run(TestNG.java:708) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73) at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124) Caused by: java.sql.SQLException: ORA-00904: "WIDGET_ID": invalid identifier at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:145) at oracle.jdbc.driver.T2CConnection.checkError(T2CConnection.java:789) at oracle.jdbc.driver.T2CConnection.checkError(T2CConnection.java:715) at oracle.jdbc.driver.T2CPreparedStatement.executeForDescribe(T2CPreparedStatement.java:605) at oracle.jdbc.driver.T2CPreparedStatement.executeForRows(T2CPreparedStatement.java:843) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1270) at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3415) at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3498) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2268) ... 35 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
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2190) JDBCTransaction.isActive() should report false if jdbcContext.connection().isClosed()

by Jeffrey Bennett (JIRA)

JDBCTransaction.isActive() should report false if jdbcContext.connection().isClosed() ------------------------------------------------------------------------------------- Key: HHH-2190 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2190 Project: Hibernate3 Type: Bug Components: core Reporter: Jeffrey Bennett In error-handling routines, I use Transaction.isActive() to determine if it is 'safe' to perform Transaction.rollback(). If the Session has previously closed, Transaction.isActive() mis-reports that the transaction is still alive when it is not. I'll grant that the JavaDoc for isActive indicates it is the 'local transaction', not the underlying transaction, but since there is no way to delve into the underlying connection in the public API, that is really a cop-out. If you don't like the idea of modifying the behavior of isActive(), how about exposing a 'public Connection connection()' method that exposes the connection? -- 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
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3058) When using native sql query and multiple selects with setMaxResults, Hibernate inserts the TOP statement in the first query

by Sean Blaes (JIRA)

When using native sql query and multiple selects with setMaxResults, Hibernate inserts the TOP statement in the first query --------------------------------------------------------------------------------------------------------------------------- Key: HHH-3058 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3058 Project: Hibernate3 Issue Type: Bug Components: query-sql Affects Versions: 3.2.4.sp1 Environment: Hibernate 3.2.4sp1, Microsoft SQL Server Reporter: Sean Blaes Priority: Minor When using a query similar to the following: DECLARE @SUB_TABLE TABLE( ID INT ) INSERT INTO @SUB_TABLE SELECT ID FROM FOO SELECT * FROM BAR INNER JOIN @SUB_TABLE ON ... Then if I call setMaxResults(100) on the query object. It inserts "TOP 100" in the first query, which isn't really what would be expected. Since the second SELECT actually consists of the data that will be returned, the TOP 100 statement should go there. I'd expect it's an easy fix. Just start your search for SELECT from the bottom rather than the top. However, I guess you have to make sure you're not hitting a subquery of a larger select either... I may try cooking up a patch this weekend for this if I can find the time, and I'll attach it to this issue if I do. -- 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
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3405) Add support for Unicode aware MS SQL Server dialect

by Chris Larun (JIRA)

Add support for Unicode aware MS SQL Server dialect --------------------------------------------------- Key: HHH-3405 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3405 Project: Hibernate3 Issue Type: New Feature Components: core Affects Versions: 3.2.6 Reporter: Chris Larun Cf. http://jira.atlassian.com/browse/CONF-4786 for a description of the issue. http://forum.hibernate.org/viewtopic.php?t=941781&highlight=sqlserver+dia... for a possible solution. -- 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-3905) Improve FieldInterceptionHelper perfomance

by Sergey Vladimirov (JIRA)

Improve FieldInterceptionHelper perfomance ------------------------------------------ Key: HHH-3905 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3905 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.3.1 Reporter: Sergey Vladimirov Priority: Minor Attachments: patch.txt do not iterate over interfaces, use Class.isAssignableFrom -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues June 2010