August 2008 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2586) Hibernate Serializable classes do not declare serialVersionUID

by Manuel Dominguez Sarmiento (JIRA)

Hibernate Serializable classes do not declare serialVersionUID -------------------------------------------------------------- Key: HHH-2586 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2586 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga, 3.2.0.cr5, 3.2.0.cr4, 3.2.0.cr3, 3.2.0.cr2, 3.2.0 cr1, 3.1.3, 3.2.0.alpha2, 3.2.0.alpha1, 3.1.2, 3.1.1, 3.1, 3.1 rc3, 3.1 rc2, 3.1 rc 1, 3.1 beta 2, 3.1 beta 1, 3.0.5, 3.0.4, 3.0.3, 3.0.2, 3.0.1, 3.0 final, 3.0 rc 1, 3.0 beta 4, 3.0 beta 3, 3.0 beta 2, 3.0 beta 1, 3.0 alpha Environment: Not specific to any database, platform or Hibernate version. Reporter: Manuel Dominguez Sarmiento None of the Serializable classes in Hibernate declare serialVersionUID (see http://www.hibernate.org/hib_docs/v3/api/serialized-form.html#org.hiberna...). This is recommended practice for ALL classes that implement the Serializable interface (see Joshua Bloch's Effective Java - Item #54). Adding these fields is trivial and takes little effort, but is a great enhancement if you are serializing Hibernate classes. For instance, we upgraded from Hibernate 3.2.2 to 3.2.3 in our production servers. We serialize process state (which sometimes includes references to Hibernate-managed entities) every 30 seconds or so and on shutdown, so in the event of failures or re-deployment, the processes can continue where they left off. We had a huge surprise when deserialization failed completely because AbstractPersistentCollection had slightly changed between the 3.2.2 and 3.2.3 releases, and this caused the automatically-generated default serialVersionUID to change, even though the changes in the serialized form are compatible as far as we can tell. -- 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

16 years, 4 months

4
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3379) Dialect support for SQL comments

by Daniel Bell (JIRA)

Dialect support for SQL comments -------------------------------- Key: HHH-3379 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3379 Project: Hibernate3 Issue Type: Patch Affects Versions: 3.2.6 Environment: Hibernate 3.2.6.ga, Informix 7.31 Reporter: Daniel Bell Attachments: hibernate.dialect.patch I have recently tried turning on SQL comments in hibernate 3.2.6.ga. However, I found that our database (informix 7.31) did not support SQL where the comment was at the start of the comment. Instead, the comment needed to be after the SQL. For example: /* not accepted by informix 7.31*/ select * from systables; select * from systables /* accepted by informix 7.31*/ Because of this, I have added a method to the Dialect for adding comments: /** * Add a comment to the SQL string. * * @param sql StringBuffer holding the SQL. * @param comment Comment to add to the SQL. May be null. */ public void addCommentToSql(StringBuffer sql, String comment) { if (StringHelper.isNotEmpty(comment)) sql.insert(0, "/* " + comment + " */ "); } Thus, the default implementation provides the same functionality as before. However, derived Dialects may override this method to add the comment in a different location. It is also possible to add additional comments in the derived Dialect. In our case, we also add the Java thread ID. -- 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

16 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3451) Boss / sub-ordinate relation

by PANDITHA L (JIRA)

Boss / sub-ordinate relation ---------------------------- Key: HHH-3451 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3451 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.3.0.GA Environment: JSF JBOSS Hibernate Reporter: PANDITHA L Priority: Trivial I have an employee table and corresponding Class defined with hbm.xml file. I am using a uniq column (user_id) which is not primary key as my requirement demands it. The problem is this table contains a filed boss_01 which references to user_id so making it one-to-many (i.e user_id to boss_01) mapping on self table. Now how can I access the sub-ordinates(childs) of a given employee? I tried in the below fashion. <class name="mfhr.tables.Employee" table="user"> <id name="id" column="ID_" type="java.lang.Long"> <generator class="increment"/> </id> <property name="user_id" column="user_id" type="java.lang.String" /> <many-to-one name="boss_01" column="boss_01" class="mfhr.tables.Employee" property-ref="user_id" not-null="true" /> <set name="children"> <key column="boss_01" property-ref="user_id" /> <one-to-many class="mfhr.tables.Employee" /> </set> </class> but, When checked in db logs sql is trying to select childs with primary key column rather than user_id. Any help in this regard. -- 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

16 years, 4 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-245) Add ReaderStratregy.destroy() method

by Emmanuel Bernard (JIRA)

Add ReaderStratregy.destroy() method ------------------------------------ Key: HSEARCH-245 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-245 Project: Hibernate Search Issue Type: Improvement Components: query Reporter: Emmanuel Bernard Fix For: 3.1.0.Beta2 ReaderProvider typically keep IndexReaders open till they are in use or if the index has been updated. But it has no hook to close the "current" IndexReaders when Hibernate Search goes down. I imagine the current code can become problematic on some VMs if we do lots of hot redeployments. See hibernate-dev: Hibernate Search: ReaderProvider.destroy() -- 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

16 years, 4 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-235) provide a destroy() method in ReaderProvider

by Emmanuel Bernard (JIRA)

provide a destroy() method in ReaderProvider -------------------------------------------- Key: HSEARCH-235 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-235 Project: Hibernate Search Issue Type: New Feature Components: query Reporter: Emmanuel Bernard Fix For: 3.1.0.Beta2 -- 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

16 years, 4 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2625) allow DetachedCriteria to work with StatelessSession

by Mario Ivankovits (JIRA)

allow DetachedCriteria to work with StatelessSession ---------------------------------------------------- Key: HHH-2625 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2625 Project: Hibernate3 Issue Type: Improvement Components: query-criteria Affects Versions: 3.2.4.sp1 Reporter: Mario Ivankovits Attachments: DetachedCriteriaWithStatelessSession.diff The attached patch add a new method to DetachedCriteria to make it work with StatelessSession. -- 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

16 years, 4 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HBX-729) boolean types mapped to bit in MySQL 5 not working with EJB3 in JBoss 4.0.4.GA

by Daniel Pocock (JIRA)

boolean types mapped to bit in MySQL 5 not working with EJB3 in JBoss 4.0.4.GA ------------------------------------------------------------------------------ Key: HBX-729 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-729 Project: Hibernate Tools Type: Bug Versions: 3.2beta6 Environment: Debian Reporter: Daniel Pocock I define a property with type="boolean" in my .hbm.xml The generated SQL column defaults to bit(1). However, when using JBoss 4.0.4.GA and MySQL 5.0.22, reading the property (getXXX()) always return false If I force hbm2sql to generate a tinyint column, the boolean works as I would have expected: <column name="myColumn" sql-type="tinyint"/> -- 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

16 years, 4 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3442) StaleObjectStateException logs unnecessary stacktrace

by Tom van den Berge (JIRA)

StaleObjectStateException logs unnecessary stacktrace ----------------------------------------------------- Key: HHH-3442 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3442 Project: Hibernate3 Issue Type: Improvement Affects Versions: 3.3.0.GA Reporter: Tom van den Berge Priority: Minor When using optimistic locking, and stale state is detected, a StaleObjectStateException is thrown. This exception is caught in AbstractFlushingEventListener, logged as error, including a stacktrace, and then thrown again. It would be better not to log the stacktrace in this situation, since it's up to the client code to deal with the exception. If the client code doesn't handle optimistic locking exceptions, it can choose to log the stacktrace itself, or otherwise do something useful with the exception, such as retrying. Currently, the stacktrace is always logged by Hibernate, also if the client code recovers from the exception, which is a bit confusing when looking at the logs. Also the fact that this particular exception is logged with severity ERROR is inappropriate. It's up to the client code to decide if it's an error. I suggest the following change to AbstractFlushingEventListener: Current code: catch (HibernateException he) { log.error("Could not synchronize database state with session", he); throw he; } Suggested code: catch (StaleObjectStateException e) { log.warn("Could not synchronize database state with session", e.getMessage()); throw e; } catch (HibernateException he) { log.error("Could not synchronize database state with session", he); throw he; } -- 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

16 years, 4 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3388) Problem mixing implicit and explicit joins - Ok in Hib2 not in Hib3

by Philippe Chaléat (JIRA)

Problem mixing implicit and explicit joins - Ok in Hib2 not in Hib3 ------------------------------------------------------------------- Key: HHH-3388 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3388 Project: Hibernate3 Issue Type: Bug Reporter: Philippe Chaléat Trying to migrate a rather large app from Hibernate 2.1 to Hibernate, we face a blocking problem. With Hibernate 3, some of our queries generate invalid SQL. I found in the forum that this problem has been noticed by someone else (but no answer) : http://forum.hibernate.org/viewtopic.php?t=963196&highlight=join+ora00904 We manage to reproduce the problem with the following query. With Hibernate 2, mixing explicit and implicit joins produced an SQL query with all "theta style" joins at the end of the query. In Hibernate 3, ANSI and "theta style" are mixed, which Oracle doesn't like. HBM: select a.description, a.seller, b.item.description " + "from org.hibernate.auction.AuctionItem a inner join a.bids b [java] SQL: [java] select [java] auctionite0_.description as col_0_0_, [java] auctionite0_.seller as col_1_0_, [java] auctionite3_.description as col_2_0_, [java] user2_.id as id2_, [java] user2_.userName as userName2_, [java] user2_."password" as password3_2_, [java] user2_.email as email2_, [java] user2_.firstName as firstName2_, [java] user2_."initial" as initial6_2_, [java] user2_.lastName as lastName2_ [java] from [java] AuctionItem auctionite0_ [java] inner join [java] Bid bids1_ [java] on auctionite0_.id=bids1_.item, [java] AuctionItem auctionite3_ [java] inner join [java] AuctionUser user2_ [java] on auctionite0_.seller=user2_.id [java] where [java] bids1_.item=auctionite3_.id Erreur: [java] org.hibernate.exception.SQLGrammarException: could not execute query [java] at org.hibernate.exception.SQLStateConverter.convert(SQLStateCon verter.java:67) [java] at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExcep tionHelper.java:43) [java] at org.hibernate.loader.Loader.doList(Loader.java:2216) [java] at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java: 2104) [java] at org.hibernate.loader.Loader.list(Loader.java:2099) [java] at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:37 8) [java] at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslato rImpl.java:338) [java] at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryP lan.java:172) [java] at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121) [java] at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79) [java] at org.hibernate.auction.Main.testOracleJoins(Main.java:359) -- 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

16 years, 4 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3457) Possibility to convert hibernate entities to POJOs

by Anton Kuzmin (JIRA)

Possibility to convert hibernate entities to POJOs -------------------------------------------------- Key: HHH-3457 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3457 Project: Hibernate3 Issue Type: Improvement Reporter: Anton Kuzmin Attachments: killLazyInitializationException.java In the project I am working on I need to convert some hibernate entities to xml using castor marshaller. At some point I encountered a problem with LazyInitializationException when castor read the fields that were not initialized. Initializing these fields is not acceptable since it would be a serious performance hit. I think there should exist a possibility to convert a hibernate entity to a POJO or to force initialization of lazy collections and proxies (what I did in attached workaround killLazyInitializationException.java) -- 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

16 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2008