[Hibernate-JIRA] Created: (HHH-2434) No standard way to calculate date intervals in HQL
by Don Smith (JIRA)
No standard way to calculate date intervals in HQL
--------------------------------------------------
Key: HHH-2434
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2434
Project: Hibernate3
Type: Improvement
Components: core
Versions: 3.2.0.ga
Environment: All
Reporter: Don Smith
Priority: Minor
Date interval calculation is supported differently on different database platforms. Some allow direct arithmetic on columns, i.e. enddate - startdate. Some require functions, datediff(), timestampdiff(), etc. This causes cross-platform issues. For instance, an application I work on has to figure out the dialect that's in use (out of the four we currently support) and create the HQL string differently for each platform. This is undesirable, since we use Hibernate to enable platform neutrality; our installer asks which database the customer wants to deploy to, and sets the dialect. We'd like our codebase to be free of dialect-specific code.
I propose a standard solution for this, either direct date arithmetic, or a function defintion that is ported across dialects. Timestampdiff seems to be a fairly standard function, although DB2 has different syntax than MySQL and Derby. I've seen hints that timestampdiff is part of the ANSI SQL standard, but do not have access to the documents to determine if that is the case.
--
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, 3 months
[Hibernate-JIRA] Created: (HHH-2459) Problem with <parent> for 2+ levels of components
by Kevin Bragh (JIRA)
Problem with <parent> for 2+ levels of components
-------------------------------------------------
Key: HHH-2459
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2459
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Environment: Hibernate 3.2.2, Tested on PostgreSQL and HSQL
Reporter: Kevin Bragh
Attachments: test.zip
I have tested several scenarios similar to the above, and I have searched and posted to the forum with no response.
I have attached the faulty code to the thread.
I have a main class (A) with 3 components recusively included as follows:
A -> B -> C <-> D
In the case above, D has a <parent> property to C.
While loading an instance of A, it seems that D.setC(...) is called with the value of the main class A, and not of parent C.
I don't know if this is a bug, or if parent is not recusively supported.
Any help is appreciated.
Thks, K.
NB: I have tried many different examples (with list and composite-element, etc.) and they all fail with 2+ levels of recursion.
Log
-----
2007-03-01 14:53:07,843 DEBUG [org.hibernate.impl.SessionImpl] - <opened session at timestamp: 4803613441277952>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.transaction.JDBCTransaction] - <begin>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.jdbc.ConnectionManager] - <opening JDBC connection>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <total checked-out connections: 0>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <using pooled JDBC connection, pool size: 0>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.transaction.JDBCTransaction] - <current autocommit status: false>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.jdbc.JDBCContext] - <after transaction begin>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.event.def.DefaultSaveOrUpdateEventListener] - <saving transient instance>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.event.def.AbstractSaveEventListener] - <saving [test.hibernate.recurse.A#<null>]>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.event.def.AbstractSaveEventListener] - <executing insertions>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.engine.Versioning] - <using initial version: 0>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Inserting entity: test.hibernate.recurse.A (native id)>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Version: 0>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open PreparedStatement (open PreparedStatements: 0, globally: 0)>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.SQL] - <insert into TEST_A (NO_VERSION, VAL, VAL_B, VAL_C, VAL_D, UID) values (?, ?, ?, ?, ?, null)>
Hibernate: insert into TEST_A (NO_VERSION, VAL, VAL_B, VAL_C, VAL_D, UID) values (?, ?, ?, ?, ?, null)
2007-03-01 14:53:07,859 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <preparing statement>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Dehydrating entity: [test.hibernate.recurse.A#<null>]>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 1>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 2>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 3>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 4>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 5>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close PreparedStatement (open PreparedStatements: 1, globally: 1)>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <closing statement>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open PreparedStatement (open PreparedStatements: 0, globally: 0)>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.SQL] - <call identity()>
Hibernate: call identity()
2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <preparing statement>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.id.IdentifierGeneratorFactory] - <Natively generated identity: 1>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close PreparedStatement (open PreparedStatements: 1, globally: 1)>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <closing statement>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <flushing session>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <processing flush-time cascades>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <dirty checking collections>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushing entities and processing referenced collections>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Processing unreferenced collections>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Scheduling collection removes/(re)creates/updates>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <listing entities:>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <test.hibernate.recurse.A{val=0, b=component[valB,c]{valB=0, c=component[valC,d]{d=component[valD]{valD=0}, valC=0}}, id=1, version=0}>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <executing flush>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <post flush>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <commit>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <automatically flushing session>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <flushing session>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <processing flush-time cascades>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <dirty checking collections>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushing entities and processing referenced collections>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Processing unreferenced collections>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Scheduling collection removes/(re)creates/updates>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <listing entities:>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <test.hibernate.recurse.A{val=0, b=component[valB,c]{valB=0, c=component[valC,d]{d=component[valD]{valD=0}, valC=0}}, id=1, version=0}>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <executing flush>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <post flush>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.JDBCContext] - <before transaction completion>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <before transaction completion>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <committed JDBC Connection>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.JDBCContext] - <after transaction completion>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <aggressively releasing JDBC connection>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <closing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <returning connection to pool, pool size: 1>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <after transaction completion>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <closing session>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <connection already null in cleanup : no action>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <opened session at timestamp: 4803613441597440>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <begin>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <opening JDBC connection>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <total checked-out connections: 0>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <using pooled JDBC connection, pool size: 0>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <current autocommit status: false>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.JDBCContext] - <after transaction begin>
2007-03-01 14:53:07,906 DEBUG [org.hibernate.engine.query.QueryPlanCache] - <unable to locate HQL query plan in cache; generating (from test.hibernate.recurse.A)>
2007-03-01 14:53:07,921 DEBUG [org.hibernate.jdbc.ConnectionManager] - <running Session.finalize()>
2007-03-01 14:53:08,000 DEBUG [org.hibernate.hql.ast.QueryTranslatorImpl] - <parse() - HQL: from test.hibernate.recurse.A>
2007-03-01 14:53:08,015 DEBUG [org.hibernate.hql.ast.AST] - <--- HQL AST ---
\-[QUERY] 'query'
\-[SELECT_FROM] 'SELECT_FROM'
\-[FROM] 'from'
\-[RANGE] 'RANGE'
\-[DOT] '.'
+-[DOT] '.'
| +-[DOT] '.'
| | +-[IDENT] 'test'
| | \-[IDENT] 'hibernate'
| \-[IDENT] 'recurse'
\-[IDENT] 'A'
>
2007-03-01 14:53:08,031 DEBUG [org.hibernate.hql.ast.ErrorCounter] - <throwQueryException() : no errors>
2007-03-01 14:53:08,078 DEBUG [org.hibernate.hql.antlr.HqlSqlBaseWalker] - <select << begin [level=1, statement=select]>
2007-03-01 14:53:08,093 DEBUG [org.hibernate.hql.ast.tree.FromElement] - <FromClause{level=1} : test.hibernate.recurse.A (no alias) -> a0_>
2007-03-01 14:53:08,093 DEBUG [org.hibernate.hql.antlr.HqlSqlBaseWalker] - <select : finishing up [level=1, statement=select]>
2007-03-01 14:53:08,093 DEBUG [org.hibernate.hql.ast.HqlSqlWalker] - <processQuery() : ( SELECT ( FromClause{level=1} TEST_A a0_ ) )>
2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.HqlSqlWalker] - <Derived SELECT clause created.>
2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.util.JoinProcessor] - <Using FROM fragment [TEST_A a0_]>
2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.antlr.HqlSqlBaseWalker] - <select >> end [level=1, statement=select]>
2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.AST] - <--- SQL AST ---
\-[SELECT] QueryNode: 'SELECT' querySpaces (TEST_A)
+-[SELECT_CLAUSE] SelectClause: '{derived select clause}'
| +-[SELECT_EXPR] SelectExpressionImpl: 'a0_.UID as UID0_' {FromElement{explicit,not a collection join,not a fetch join,fetch non-lazy properties,classAlias=null,role=null,tableName=TEST_A,tableAlias=a0_,origin=null,colums={,className=test.hibernate.recurse.A}}}
| \-[SQL_TOKEN] SqlFragment: 'a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_'
\-[FROM] FromClause: 'from' FromClause{level=1, fromElementCounter=1, fromElements=1, fromElementByClassAlias=[], fromElementByTableAlias=[a0_], fromElementsByPath=[], collectionJoinFromElementsByPath=[], impliedElements=[]}
\-[FROM_FRAGMENT] FromElement: 'TEST_A a0_' FromElement{explicit,not a collection join,not a fetch join,fetch non-lazy properties,classAlias=null,role=null,tableName=TEST_A,tableAlias=a0_,origin=null,colums={,className=test.hibernate.recurse.A}}
>
2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.ErrorCounter] - <throwQueryException() : no errors>
2007-03-01 14:53:08,125 DEBUG [org.hibernate.hql.ast.QueryTranslatorImpl] - <HQL: from test.hibernate.recurse.A>
2007-03-01 14:53:08,125 DEBUG [org.hibernate.hql.ast.QueryTranslatorImpl] - <SQL: select a0_.UID as UID0_, a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_ from TEST_A a0_>
2007-03-01 14:53:08,125 DEBUG [org.hibernate.hql.ast.ErrorCounter] - <throwQueryException() : no errors>
2007-03-01 14:53:08,140 DEBUG [org.hibernate.engine.query.HQLQueryPlan] - <HQL param location recognition took 0 mills (from test.hibernate.recurse.A)>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.query.QueryPlanCache] - <located HQL query plan in cache (from test.hibernate.recurse.A)>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.query.HQLQueryPlan] - <find: from test.hibernate.recurse.A>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.QueryParameters] - <named parameters: {}>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open PreparedStatement (open PreparedStatements: 0, globally: 0)>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.SQL] - <select a0_.UID as UID0_, a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_ from TEST_A a0_>
Hibernate: select a0_.UID as UID0_, a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_ from TEST_A a0_
2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <preparing statement>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open ResultSet (open ResultSets: 0, globally: 0)>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <processing result set>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <result set row: 0>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.LongType] - <returning '1' as column: UID0_>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <result row: EntityKey[test.hibernate.recurse.A#1]>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <Initializing object from ResultSet: [test.hibernate.recurse.A#1]>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Hydrating entity: [test.hibernate.recurse.A#1]>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: NO2_0_>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL0_>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL4_0_>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL5_0_>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL6_0_>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.TwoPhaseLoad] - <Version: 0>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <done processing result set (1 rows)>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close ResultSet (open ResultSets: 1, globally: 1)>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close PreparedStatement (open PreparedStatements: 1, globally: 1)>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <closing statement>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <total objects hydrated: 1>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.TwoPhaseLoad] - <resolving associations for [test.hibernate.recurse.A#1]>
2007-03-01 14:53:08,156 ERROR [org.hibernate.property.BasicPropertyAccessor] - <IllegalArgumentException in class: test.hibernate.recurse.D, setter method of property: c>
2007-03-01 14:53:08,156 ERROR [org.hibernate.property.BasicPropertyAccessor] - <expected type: test.hibernate.recurse.C, actual value: test.hibernate.recurse.A>
Exception stack trace
-----------------------------
Exception in thread "main" org.hibernate.PropertyAccessException: IllegalArgumentException occurred while calling setter of test.hibernate.recurse.D.c
at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:104)
at org.hibernate.tuple.PojoComponentTuplizer.setParent(PojoComponentTuplizer.java:132)
at org.hibernate.type.ComponentType.instantiate(ComponentType.java:438)
at org.hibernate.type.ComponentType.resolve(ComponentType.java:524)
at org.hibernate.type.ComponentType.resolve(ComponentType.java:528)
at org.hibernate.type.ComponentType.resolve(ComponentType.java:528)
at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:113)
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:842)
at org.hibernate.loader.Loader.doQuery(Loader.java:717)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:223)
at org.hibernate.loader.Loader.doList(Loader.java:2147)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2026)
at org.hibernate.loader.Loader.list(Loader.java:2021)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:369)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:298)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:137)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1014)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
at test.hibernate.recurse.Main.main(Main.java:67)
Caused by: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:42)
... 18 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, 4 months
[Hibernate-JIRA] Created: (HHH-2447) Connection leak if logAndClearWarnings throws
by Jeppe N. Madsen (JIRA)
Connection leak if logAndClearWarnings throws
----------------------------------------------
Key: HHH-2447
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2447
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3, 3.2.2
Environment: Database product name : DB2/NT
Database product version : SQL08025
JDBC driver name : IBM DB2 JDBC Universal Driver Architecture
Hibernate 3.1.3 (seems to exist in 3.2.2 as well)
JDBC driver version : 2.9.31
Reporter: Jeppe N. Madsen
Priority: Minor
In ConnectionManager.closeConnection, logAndClearWarnings is called before connection.close() is called. If this call throws an exception, the connection is never closed.
We have observed that DB2 sometimes throws an Error because the SQLWarning chain is wrong:
[14-02-07 11:36:30:889 CET] 10b0b533 WebGroup E SRVE0026E: [Servlet Error]-[SQLWarning chain holds value that is not a SQLWarning]: java.lang.Error: SQLWarning chain holds value that is not a SQLWarning
at java.sql.SQLWarning.getNextWarning(SQLWarning.java:109)
at org.hibernate.util.JDBCExceptionReporter.logWarnings(JDBCExceptionReporter.java:50)
at org.hibernate.util.JDBCExceptionReporter.logWarnings(JDBCExceptionReporter.java:33)
at org.hibernate.util.JDBCExceptionReporter.logAndClearWarnings(JDBCExceptionReporter.java:22)
at org.hibernate.jdbc.ConnectionManager.closeConnection(ConnectionManager.java:443)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:379)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:318)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:293)
--
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, 4 months
[Hibernate-JIRA] Created: (HHH-2075) many-to-one in a properties element causes strange PropertyValueException on flush
by Josh Moore (JIRA)
many-to-one in a properties element causes strange PropertyValueException on flush
----------------------------------------------------------------------------------
Key: HHH-2075
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2075
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr4
Environment: HSQLDB
Hibernate r10478
Reporter: Josh Moore
Attachments: exception.txt, log.txt, properties.zip
Full test directory zip (org/hibernate/test/properties) attached. But to summarize, the following test will fail on flush after a simple merge. The exception thrown says that Pixels.sizeC is null -- though it's clearly set in the test case.
<code>
Image i = new Image();
Pixels p = new Pixels();
p.setSizeC(new Integer(2));
p.setImage(i); // This calls i.getPixels().add(p)
// i.setPixels(null); // This makes it work.
Session s = openSession();
Transaction t = s.beginTransaction();
// s.merge(i); // This makes it work.
p = (Pixels) s.merge(p); // This fails with the exception below.
t.commit();
s.close();
</code>
The properties element in question is:
<code>
<properties name="defaultPixelsTag">
<property name="defaultPixels" type="java.lang.Boolean"/>
<many-to-one name="image" class="Image" column="image"
not-null="true" unique="false" insert="true" update="true"
cascade="lock,merge,persist,replicate,refresh,save-update"
/>
</properties>
</code>
The reverse side is:
<code>
<set
name="pixels"
lazy="true"
inverse="true"
cascade="lock,merge,persist,replicate,refresh,save-update">
<key column="image" not-null="false"/>
<one-to-many class="Pixels"/>
</set>
</code>
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-2166) Long "in" lists in queries results in a Java stack overflow exception.
by Philip R. "Pib" Burns (JIRA)
Long "in" lists in queries results in a Java stack overflow exception.
----------------------------------------------------------------------
Key: HHH-2166
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2166
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.ga
Environment: Hibernate 3.2.0.cr3 through 3.2.0.ga (at least). Any standard deployment of Sun's JVM on Windows, Linux, or Mac OS X (and presumably other platforms like Solaris)
Reporter: Philip R. "Pib" Burns
Attachments: NodeTraverser.java
With Hibernate 320ga a long "in" list can result in a stack overflow error during the parsing stage. For example, a query element like
where x in (:x)
or a manually constructed
where x in (1,2,3 .....)
can generate a stack overflow if the number of elements referenced by x exceeds a number dependent upon the amount of available stack space. For many JVMs, the limit is between 9,000 and 10,000 assuming a relatively empty stack at the point of query execution. We have applications which occasionally use lists several times this size.
The stack overflow occurs in org.hibernate.hql.ast.util.NodeTraverser which uses a recursive algorithm to walk a parse tree. Long "in" lists generate a subtree of depth about equal to the number of elements in the list. A sufficiently long list results in a stack overflow when NodeTraverser's internal method visitDepthFirst calls itself too many times.
The solution is to replace the recursive tree walking strategy with an iterative one that does not use up stack space. I am attaching the source for a replacement version of . NodeTraverser which implements the iterative tree walking method.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-2305) refresh throws exception when database has been altered with a delete
by Markus Heiden (JIRA)
refresh throws exception when database has been altered with a delete
---------------------------------------------------------------------
Key: HHH-2305
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2305
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: Hibernate 3.2.1, Oracle 9.2
Reporter: Markus Heiden
Attachments: hibernate.zip
First I save an entity with a collection of cascading entities in it and flush. Then I delete these cascaded entities with a sql query. When I now do a refresh on the entity an exception is thrown, because the cascaded entities couldn't be found in the database. I expected these entities to be deleted from the (in memory) collection of the entity instead.
Test case is attached. Stacktrace of test case:
Hibernate: select c0_.id as id2_0_, c0_.c as c2_0_ from C c0_ where c0_.id=?
org.hibernate.UnresolvableObjectException: No row with the given identifier exists: [hibernate.refresh.C#30003]
at org.hibernate.UnresolvableObjectException.throwIfNull(UnresolvableObjectException.java:42)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:126)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894)
at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894)
at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:39)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:902)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:886)
at hibernate.refresh.Test.main(Test.java:46)
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-2220) session.createSQLQuery(sql) translates database type CHAR(n) to Java type char instead of String
by Regis Pires Magalhaes (JIRA)
session.createSQLQuery(sql) translates database type CHAR(n) to Java type char instead of String
------------------------------------------------------------------------------------------------
Key: HHH-2220
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2220
Project: Hibernate3
Type: Bug
Components: query-sql
Versions: 3.2.0.ga
Reporter: Regis Pires Magalhaes
createSQLQuery() method translates database type CHAR(n) to Java type char instead of String when using setResultTransformer(Criteria.ALIAS_TO_ENTITY_MAP).
That happens when I do not use addScalar(). And that is the only problem that I have found when not filling return types in advance.
A workaround I have made is to concatenate the projected field with an empty string (''). See example below:
...
query.setResultTransformer(Criteria.ALIAS_TO_ENTITY_MAP);
String sqlQuery = "select s.name state from state s where s.name='PI' ";
query = session.createSQLQuery(sqlQuery);
...
result: [{STATE=P}]
name field is CHAR(2) in database definition (PostgreSQL, HSQLDB and Oracle were tested).
Note that it works when I concatenate the field used in projection with an empty string:
...
String sqlQuery = "select s.name || '' state from state s where s.name='PI' ";
...
result: [{STATE=PI}]
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-2429) SQL Character Types Incorrectly mapped to Java objects
by Tyler Van Gorder (JIRA)
SQL Character Types Incorrectly mapped to Java objects
------------------------------------------------------
Key: HHH-2429
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2429
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: Hibernate 3.2.1, Oracle10g
Reporter: Tyler Van Gorder
We have a work flow that allows the user to enter an arbitrary SQL statement to be executed by our application. We pass those queries through session.createSQLQuery().
We ran into a problem with String literals, which are reported by Oracle (ResultSetMetaData) to be CHAR. Reading the JDBC API, CHAR is a fixed length string. Hibernate is incorrectly mapping this to a Character field. We ended up overriding the Oracle dialect with our own as follows:
In our constructor, for a dialect that extends Oracle9iDialect:
super()
registerColumnType(Types.CHAR, "char($l)" );
registerHibernateType( Types.CHAR, Hibernate.STRING.getName() );
The HibernateType is the crucial one and we are overriding the behavior in the base "Dialect" class, so this appears that it would be a problem for all database variants that don't explicitly change this.
Thanks.
--
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, 6 months