March 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Closed: (HHH-1179) support inline sequence id generation on Oracle using RETURNING clause

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1179?page=c... ] Steve Ebersole closed HHH-1179. ------------------------------- Closing stale resolved issues > support inline sequence id generation on Oracle using RETURNING clause > ---------------------------------------------------------------------- > > Key: HHH-1179 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1179 > Project: Hibernate Core > Issue Type: New Feature > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.2.0 cr1 > > > A common practice on Oracle is to use sequences for id generation, but to "inline" the nextval call into the insert statement utilizing the Oracle-specific RETURNING clause to return the generated value: > insert into my_table ( id, name ) values ( sequence_name.nextval, 'blahblahblah' ) returning id > the process is very simliar to dialects supporting "insert-select-identity" -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1032) have proxy from ThreadLocalCurrentSession better handle UndeclaredThrowableException

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1032?page=c... ] Steve Ebersole closed HHH-1032. ------------------------------- Closing stale resolved issues > have proxy from ThreadLocalCurrentSession better handle UndeclaredThrowableException > ------------------------------------------------------------------------------------ > > Key: HHH-1032 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1032 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.1 rc 1 > Environment: win2k, db2 > Reporter: Barthel Steckemetz > Priority: Trivial > Original Estimate: 1h > Remaining Estimate: 1h > > In previous version of hibernate saving two object with the same id > gave an NonUniqueObjectException which could easily be caught > as it is derived from HibernateException. > However in Hibernate 3.1 rc1 I get this stacktrace: > java.lang.reflect.UndeclaredThrowableException > at $Proxy0.save(Unknown Source) > at de.ifbfag.base.db.HSession.save(HSession.java:230) > at com.ifbag.okular.base.hibernate.tst.HibInteractive.lifecycleMitExceptions(HibInteractive.java:195) > at com.ifbag.okular.base.hibernate.tst.HibInteractive.start(HibInteractive.java:56) > at com.ifbag.okular.base.hibernate.tst.HibInteractive.main(HibInteractive.java:41) > Caused by: java.lang.reflect.InvocationTargetException > 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:324) > at org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:266) > ... 5 more > Caused by: org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: [com.ifbag.okular.base.hibernate.tst.User#ifb0] > at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:154) > at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:114) > at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:186) > at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:33) > at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:175) > at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:27) > at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70) > at org.hibernate.impl.SessionImpl.fireSave(SessionImpl.java:523) > at org.hibernate.impl.SessionImpl.save(SessionImpl.java:513) > at org.hibernate.impl.SessionImpl.save(SessionImpl.java:509) > ... 10 more > where the original exception is contain in a rather ugly UndeclaredThrowableException. -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HBX-373) Autocomplete for <generator class="..."/> and <property access="field|property"/>

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-373?page=co... ] Steve Ebersole closed HBX-373. ------------------------------ Closing stale resolved issues > Autocomplete for <generator class="..."/> and <property access="field|property"/> > --------------------------------------------------------------------------------- > > Key: HBX-373 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-373 > Project: Hibernate Tools > Issue Type: Improvement > Components: eclipse > Reporter: Gavin King > Fix For: 3.1beta1 > > > Just a couple of things missing from the auto-complete functionality. -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1153) PropertiesHelper fails reading primitive values from hibernate-mapping when doc has whitespace

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1153?page=c... ] Steve Ebersole closed HHH-1153. ------------------------------- Closing stale resolved issues > PropertiesHelper fails reading primitive values from hibernate-mapping when doc has whitespace > ---------------------------------------------------------------------------------------------- > > Key: HHH-1153 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1153 > Project: Hibernate Core > Issue Type: Improvement > Environment: rc2. Any database. > Reporter: Rich MacDonald > Fix For: 3.1 > > > The PropertiesHelper class is used to extract primitives from the hibernate-mapping file. Unfortunately, it is implemented so as not to trim the values that are read from the file. So something like PropertiesHelper.getInt() will fail with a NumberFormatException if the argument contains white-space before or after the "int" value. > For those of us who generate our hibernate-mappings with whitespace, this is a problem. For example, my hilo spec written as: > <param > name="max_lo"> > 512 > </param> > will fail. It needs to be written as: > <param name="max_lo">512</param> > i.e., no whitespace between the >512< portion > I autogenerate my hibernate-mapping files, and whitespace is all or nothing for me, and since people read it... ;-) > The simple fix is to add trim() methods in the relevant methods of the PropertiesHelper class. A few min work for me, but I believe others would benefit as well. -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1578) queries inside events - scenario which fails + fix

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1578?page=c... ] Steve Ebersole closed HHH-1578. ------------------------------- Closing stale resolved issues > queries inside events - scenario which fails + fix > --------------------------------------------------- > > Key: HHH-1578 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1578 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.1.2 > Reporter: Tomasz Bech > Assignee: Steve Ebersole > > It is related to the forum topic: http://forum.hibernate.org/viewtopic.php?p=2294885#2294885. However I put full and better description below. > preInsert event is used to make query on DB - to check some integrity. > Following scenario fails: > - insert object A; > - insert object A'; (of type A, but different values than before) > - commit; > it gives stack trace: > This gives exception: > aused by: org.hibernate.exception.GenericJDBCException: could not insert: > at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:91) > at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:79) > at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) > at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2078) > at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2427) > at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:51) > at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:243) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:227) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140) > at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296) > at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) > at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1009) > at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:356) > at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:59) > at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1473) > at org.jboss.tm.TransactionImpl.beforePrepare(TransactionImpl.java:1092) > at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:306) > ... 63 more > Caused by: java.sql.SQLException: Connection handle has been closed and is unusable > at org.jboss.resource.adapter.jdbc.WrappedConnection.checkStatus(WrappedConnection.java:526) > at org.jboss.resource.adapter.jdbc.WrappedConnection.checkTransaction(WrappedConnection.java:513) > at org.jboss.resource.adapter.jdbc.WrappedStatement.checkTransaction(WrappedStatement.java:537) > at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:223) > at org.hibernate.jdbc.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:23) > at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2062) > ... 76 more > Following scenario works fine: > - insert object A > - commit; > Following scenario also works fine: > - insert object A > - insert object B > - commit; > I've spend a day to analyze the problem, as the preInsert+queries are crucial for our project. > The order of operations is as follows: > - prepareBatchStatement is called on AbstractBatcher; > - my suplied query is executed; > - prepareBatchStatement is called on AbstractBatcher; > The problem appears because the 'batchUpdate' statement is reused in second call: > public PreparedStatement prepareBatchStatement(String sql) > throws SQLException, HibernateException { > sql = getSQL( sql ); > if ( !sql.equals(batchUpdateSQL) ) { > batchUpdate=prepareStatement(sql); // calls executeBatch() > batchUpdateSQL=sql; > } > else { > log.debug("reusing prepared statement"); //here - REUSING prepare statement > log(sql); > } > return batchUpdate; > } > and it is why insert A, preinsert-query, insert B scenario works, and insert A, preinsert-query, query A' doesn't. > The query which was called just before the second insert of A' has closed its connection, but this connection belongs to batchUpdate too :(. > The function responsible for tracking if the connection cen be closed is: > public boolean hasOpenResources() { > return resultSetsToClose.size() > 0 || statementsToClose.size() > 0 ; > } > It simply doesn't take into consideration that batchUpdate also has open connection - batchUpdate is not added to the statementsToClose also (as it is in the prepareQueryStatement). > Golden patch would be to add batchUpdate to the statementsToClose map. > But the same can be reach by (this is a fix): > public boolean hasOpenResources() { > return resultSetsToClose.size() > 0 > || statementsToClose.size() > 0 > || batchUpdate != null; > } > BatchUpdate when executed (in executeBatch) is closed and set to null = its connection can be released. > I've tested the change, there is no side-effects (no leaked open connections) and the above scenario works. > (in fact full execution order is: preInsert-query, insert A, preInsert--query, insert A', but the first preInsert-query works ok.) -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-429) reference to superclass property after []

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-429?page=co... ] Steve Ebersole closed HHH-429. ------------------------------ Closing stale resolved issues > reference to superclass property after [] > ----------------------------------------- > > Key: HHH-429 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-429 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.0.3 > Reporter: Gavin King > Assignee: Steve Ebersole > > The query: > from Zoo zoo where zoo.mammals[:name].mother.bodyWeight > :w > is broken, since there is no join from the mammals to animals table -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-893) custom tuplizer are not instantiated for components

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-893?page=co... ] Steve Ebersole closed HHH-893. ------------------------------ Closing stale resolved issues > custom tuplizer are not instantiated for components > --------------------------------------------------- > > Key: HHH-893 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-893 > Project: Hibernate Core > Issue Type: Bug > Affects Versions: 3.1 beta 2 > Reporter: Davide Marchignoli > Assignee: Steve Ebersole > Fix For: 3.1 rc 1 > > > Suggested patch: > 1722c1722 > < component.addTuplizer( mode, node.attributeValue( "class" ) ); > --- > > component.addTuplizer( mode, tuplizerElem.attributeValue( "class" ) ); -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1041) Support a way to turn off automatic dirty checking.

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1041?page=c... ] Steve Ebersole closed HHH-1041. ------------------------------- Closing stale resolved issues > Support a way to turn off automatic dirty checking. > --------------------------------------------------- > > Key: HHH-1041 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1041 > Project: Hibernate Core > Issue Type: Improvement > Reporter: Jose Peleteiro > > Automatic dirty checking is a nice features, but at the old-fashioned design (dao.new(), dao.save()) it's not nice. > It may be possible to turn it off at configuration file. -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-983) Cannot define unique indexes in mapping doc, SchemaExport cannot produce unique index DDL

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-983?page=co... ] Steve Ebersole closed HHH-983. ------------------------------ Closing stale resolved issues > Cannot define unique indexes in mapping doc, SchemaExport cannot produce unique index DDL > ----------------------------------------------------------------------------------------- > > Key: HHH-983 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-983 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.0.5 > Environment: Hibernate 3.0.5 > Solaris 10 x86 > MS SQL Server (MSDE) > Reporter: Nicholas Gianniotis > > References: > http://forum.hibernate.org/viewtopic.php?t=947566 > http://opensource2.atlassian.com/projects/hibernate/browse/HHH-975 > The offered solution, unique-key="name", does not work for me. > Could you please elaborate, or explain the misunderstanding? > Thank you. -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1075) New parser "not exists" command bug

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1075?page=c... ] Steve Ebersole closed HHH-1075. ------------------------------- Closing stale resolved issues > New parser "not exists" command bug > ------------------------------------ > > Key: HHH-1075 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1075 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.0.5, 3.1 rc2 > Environment: Win XP + java 1.5 + Oracle 9 > Reporter: Michał Raczyński > Assignee: Steve Ebersole > Fix For: 3.1 rc3 > > > It is possible, that some combinations of one-argument operators are not parsed correctly. I have found an example concerning "not exists" command: > HQL: > select d.id > from Decret d > where not exists ( > select d1 > from Decret d1 > ) > is parsed with the new parser as > select > decret0_.ID as col_0_0_ > from > ZAPISY decret0_ > where > not (exists (select <===== should be (not exists ( !!!!!!! > decret1_.ID > from > ZAPISY decret1_)) > while with the old parser it's ok: > select > decret0_.ID as col_0_0_ > from > ZAPISY decret0_ > where > ( > not exists( > select > decret1_.ID > from > ZAPISY decret1_ > ) > ) -- 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

15 years, 1 month

1
0
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 2011