February 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-5) Only index an entity when it's index properties have physically changed

by Emmanuel Bernard (JIRA)

Only index an entity when it's index properties have physically changed ----------------------------------------------------------------------- Key: HSEARCH-5 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-5 Project: Hibernate Search Type: New Feature Components: engine Reporter: Emmanuel Bernard Priority: Minor -- 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, 7 months

3
11
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

12 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (EJB-265) Incorrect SQL generated for JPA QL Update statement involving multiple entities

by Alex Savitsky (JIRA)

Incorrect SQL generated for JPA QL Update statement involving multiple entities ------------------------------------------------------------------------------- Key: EJB-265 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-265 Project: Hibernate Entity Manager Type: Bug Versions: 3.2.1 Environment: Hibernate 3.2.2 GA, Oracle 9i Reporter: Alex Savitsky When generating SQL for statements like this: UPDATE Issue i SET i.dueDate = i.dueDate + 10 WHERE i.visit.branch.id = :branchId, an extra comma is generated at the end of table list: update Issue, set DUE_DATE=DUE_DATE+10 where BRANCH_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

12 years, 10 months

7
18
0 / 0

[Hibernate-JIRA] Created: (HHH-2125) Hibernate XML Mapping should not depend on dom4j

by Don Smith (JIRA)

Hibernate XML Mapping should not depend on dom4j ------------------------------------------------ Key: HHH-2125 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2125 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0 cr1, 3.2.0.cr2, 3.2.0.cr3, 3.2.0.cr4 Environment: all Reporter: Don Smith Hibernate XML mapping requires dom4j, which is one of the packages that causes the Java version of "dll hell" - applications requiring conflicting versions of jars with no way to resolve the problem in a given release of an application server or package. HIbernate should be converted to use the standard XML APIs included in the JRE 5.0 specification, when Hibernate no longer needs to support JRE 1.4.x. -- 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, 11 months

6
10
0 / 0

[Hibernate-JIRA] Created: (HHH-2052) org.hibernate.pretty.MessageHelper.collectionInfoString tries to cast wrong object to String, causes ClassCastException

by Tree 'Huggy Bear' Hugger (JIRA)

org.hibernate.pretty.MessageHelper.collectionInfoString tries to cast wrong object to String, causes ClassCastException ----------------------------------------------------------------------------------------------------------------------- Key: HHH-2052 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2052 Project: Hibernate3 Type: Bug Reporter: Tree 'Huggy Bear' Hugger Attachments: bugtest.zip Debug level logging attempted by MessageHelper falls over when constructing a loggable string for a mapped collection on the main entity. Following the code in the stacktrace, I can see that MessageHelper expects the parent key for the collection relationship to be the primary key, but it is mapped to another field of a different type via a property-ref. Hence the ClassCastException below. The work around is to set logging to INFO or higher. I have also attached a pared-down zip with the maven 2 project containing the mappings and the unit test which fails. The following JIRA issue may be the same thing: http://opensource.atlassian.com/projects/hibernate/browse/ANN-298 The following messages on the Hib forum demonstrate other interest in this issue: http://forum.hibernate.org/viewtopic.php?t=949913 http://forum.hibernate.org/viewtopic.php?t=956778 http://forum.hibernate.org/viewtopic.php?t=962471 java.lang.ClassCastException: com.nomadsoft.cortex.domain.country.basic.BasicCountry at org.hibernate.type.StringType.toString(StringType.java:44) at org.hibernate.type.NullableType.toLoggableString(NullableType.java:168) at org.hibernate.pretty.MessageHelper.collectionInfoString(MessageHelper.java:284) at org.hibernate.loader.Loader.readCollectionElement(Loader.java:972) at org.hibernate.loader.Loader.readCollectionElements(Loader.java:635) at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:580) at org.hibernate.loader.Loader.doQuery(Loader.java:689) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224) at org.hibernate.loader.Loader.loadEntity(Loader.java:1785) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:47) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:41) at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2730) at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:365) at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:346) at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123) at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:177) at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87) at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:862) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:799) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:792) at org.springframework.orm.hibernate3.HibernateTemplate$1.doInHibernate(HibernateTemplate.java:452) at org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemplate.java:366) at org.springframework.orm.hibernate3.HibernateTemplate.get(HibernateTemplate.java:446) at org.springframework.orm.hibernate3.HibernateTemplate.get(HibernateTemplate.java:440) at com.nomadsoft.cortex.infrastructure.hibernate.HibernateCountryRepository.getById(HibernateCountryRepository.java:26) at com.nomadsoft.cortex.domain.country.basic.BasicCountryService.getCountry(BasicCountryService.java:34) etc etc -- 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, 11 months

9
8
0 / 0

[Hibernate-JIRA] Created: (HHH-2455) "Could not close a JDBC result set" output very often

by Dirk Feufel (JIRA)

"Could not close a JDBC result set" output very often ----------------------------------------------------- Key: HHH-2455 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.2 Reporter: Dirk Feufel Priority: Minor If you call this type of code (like the DbTimestampType class does), the AbstractBatcher outputs a warning "Could not close a JDBC result set". The problem should be that closing the prepared statement internally also closes the associated result sets and the AbstractBatcher still has a reference to this result set. One possible solution might be to provide an additional method public void closeStatement(PreparedStatement ps, ResultSet rs); (as already present for closeQueryStatement) in the AbstractBatcher allowing to close both in the right order. PreparedStatement ps = null; try { ps = session.getBatcher().prepareStatement( timestampSelectString ); ResultSet rs = session.getBatcher().getResultSet( ps ); .... } finally { if ( ps != null ) { session.getBatcher().closeStatement( ps ); } } -- 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, 11 months

4
17
0 / 0

[Hibernate-JIRA] Created: (HHH-2079) Add pre flush event listener holding all the changed entities and the operations on them

by Shay Banon (JIRA)

Add pre flush event listener holding all the changed entities and the operations on them ---------------------------------------------------------------------------------------- Key: HHH-2079 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2079 Project: Hibernate3 Type: New Feature Components: core Versions: 3.2.0.ga Reporter: Shay Banon Is there a chance to add a pre flush event listener. The event listener will have all the entities changes about to be flushed, including the operation about to be performed on them (delete, update, create). This issue relates to HHH-1725 and the collection not processed by flush exception. Maybe there would be a chance to load the lazy collections before the actual flush operation using the mentioned listener. -- 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

4
4
0 / 0

[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

13 years

6
16
0 / 0

[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

13 years, 1 month

2
1
0 / 0

[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

13 years, 1 month

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2007