April 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2158) incorrect hql query on one-to-one with property-ref

by Sebastien Cesbron (JIRA)

incorrect hql query on one-to-one with property-ref ---------------------------------------------------- Key: HHH-2158 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2158 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Environment: hibernate 3.2.0.ga with firebird 1.5.3 and jaybird 1.5.5 driver on windows XP Reporter: Sebastien Cesbron Attachments: testhib.zip I have a one-to-one relationship with property-ref between Master and Slave2. I want to find all Master instances that have a null Slave2 instance associated. To do so my query is select master from Master master where master.slave2 is null The sql generated is select master0_.oid as oid0_, master0_.libelle as libelle0_ from Master master0_ where master0_.oid is null which seems incorrect. It checks here Master instances with null id (config files are listed below). If I do my query like this select master from Master master where master.slave2.oid is null the generated sql is ok : select master0_.oid as oid0_, master0_.libelle as libelle0_ from Master master0_, Slave2 slave2x1_ where master0_.oid=slave2x1_.myMaster and (slave2x1_.oid is null) I have attached a small eclipse project that reproduces the problem This problem may-be related to the one I have submitted as issue HHH-1849 -- 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

6
7
0 / 0

[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: (HHH-2548) when "order by" a composit object, which may be null, the result list returns only when the composit objcts not null

by Yu Deng (JIRA)

when "order by" a composit object, which may be null, the result list returns only when the composit objcts not null -------------------------------------------------------------------------------------------------------------------- Key: HHH-2548 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2548 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.3 Environment: tomcat 5.5, eclipse3.2, jre1.5, postgreSQL8.1, hibernate3 and hibernate3.2 Reporter: Yu Deng Priority: Critical <hibernate-mapping package="com.grapevinecs.ams.domain.perbranch.inv"> <class name="InvItem"> <id name="id" column="id"> <generator class="hilo"/> </id> ... <many-to-one name="transferredDetails"/>  .... </class> (another mapping file) </hibernate-mapping>> <hibernate-mapping package="com.grapevinecs.ams.domain.perbranch.inv"> <class name="InvTransferDetails" > <id name="id" column="id"> <generator class="hilo"/> </id> <property name="returnedToICBC" type="com.grapevinecs.ams.dao.BooleanInteger" not-null="true"/> ... </class> </hibernate-mapping> Probelm: 1) The result returns 3000 records ---- select count(*) from InvItem c where upper(c.invType) LIKE '%D%' and c.invSeries.closed = '0' and c.branch =60551 order by c.transferredDetails.returnedToICBC asc, c.stamp asc,c.invNmbr asc 2) result List return size 0 by this query --- from InvItem c where upper(c.invType) LIKE '%D%' and c.invSeries.closed = '0' and c.branch =60551 order by c.transferredDetails.returnedToICBC asc, c.stamp asc,c.invNmbr asc 1) is correct but 2) is not correct. only when transferredDetails in InvItem not null be returned. in case 2), I have no transferredDetails not null. after I excuted the query 2), even I remove "c.transferredDetails.returnedToICBC asc", the result is still return nothing. -- 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, 9 months

3
2
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-2515) Remove all documentation about HAR, it is deprecated

by Christian Bauer (JIRA)

Remove all documentation about HAR, it is deprecated ---------------------------------------------------- Key: HHH-2515 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2515 Project: Hibernate3 Type: Improvement Components: documentation Reporter: Christian Bauer Priority: Critical Clearly not one of the best ideas we ever had is the HAR deployment. It should now be considered deprecated (superseded by the EJB3/JPA deployment model) and any documentation about it should be removed. This includes JBoss AS user guides, wiki pages, etc. If you have any objects and think that HAR is a fantastic thing, raise them here. -- 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
11
0 / 0

[Hibernate-JIRA] Created: (HHH-2511) generated="insert/always" ignored for property in composite-element?

by James Garrison (JIRA)

generated="insert/always" ignored for property in composite-element? -------------------------------------------------------------------- Key: HHH-2511 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2511 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.2 Environment: Hibernate 3.2.2, Windows XP SP2, Oracle 9i Reporter: James Garrison Priority: Minor I have a composite-element (in an idbag) that has a db-generated timestamp property. I have defined the property with update="false" insert="false" generated="insert", but Hibernate is trying to insert a null value when saving a transient object. See below, the "createTs" property (column=CREATE_TS) in the "comments" composite-element. DDL: create table CR_COMMENT ( COMMENT_ID integer not null, REQ_ID integer not null, CREATE_TS timestamp default sysdate not null, SECTION_ID char(1) not null, USER_ID varchar2(20) not null, TEXT varchar2(4000) not null, primary key(COMMENT_ID), foreign key(REQ_ID) references CR_REQUEST (REQ_ID) on delete cascade ); Mapping: <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping package="com.wholefoods.ittoolkit.ws.ccf"> <class name="Request" table="CR_REQUEST"> <id name="reqId" column="REQ_ID" type="long"> <generator class="sequence"> <param name="sequence">CR_REQUEST_ID</param> </generator> </id> [snip] <idbag name="comments" table="CR_COMMENT"> <collection-id type="long" column="COMMENT_ID"> <generator class="sequence"> <param name="sequence">CR_COMMENT_ID</param> </generator> </collection-id> <key column="REQ_ID" /> <composite-element class="Comment"> <property name="createTs" column="CREATE_TS" type="calendar" access="field" update="false" insert="false" generated="insert" /> <property name="sectionId" column="SECTION_ID" /> <property name="userId" column="USER_ID" /> <property name="text" column="TEXT"/> </composite-element> </idbag> </class> </hibernate-mapping> Log Output: Hibernate: /* insert collection row com.wholefoods.ittoolkit.ws.ccf.Request.comments */ insert into ITTOOLKIT.CR_COMMENT (REQ_ID, COMMENT_ID, CREATE_TS, SECTION_ID, USER_ID, TEXT) values (?, ?, ?, ?, ?, ?) 10:15:01,659 DEBUG org.hibernate.jdbc.AbstractBatcher:476 - preparing statement 10:15:01,675 DEBUG org.hibernate.type.LongType:133 - binding '47' to parameter: 1 10:15:01,675 DEBUG org.hibernate.type.LongType:133 - binding '7' to parameter: 2 10:15:01,675 DEBUG org.hibernate.type.CalendarType:126 - binding null to parameter: 3 10:15:01,675 DEBUG org.hibernate.type.StringType:133 - binding 'A' to parameter: 4 10:15:01,690 DEBUG org.hibernate.type.StringType:133 - binding 'garrisoj' to parameter: 5 10:15:01,690 DEBUG org.hibernate.type.StringType:133 - binding 'This is a test comment' to parameter: 6 10:15:01,690 DEBUG org.hibernate.persister.collection.AbstractCollectionPersister:1172 - done inserting collection: 1 rows inserted 10:15:01,690 DEBUG org.hibernate.jdbc.AbstractBatcher:44 - Executing batch size: 1 10:15:01,737 DEBUG org.hibernate.jdbc.AbstractBatcher:366 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1) 10:15:01,737 DEBUG org.hibernate.jdbc.AbstractBatcher:525 - closing statement 10:15:01,768 DEBUG org.hibernate.util.JDBCExceptionReporter:69 - Could not execute JDBC batch update [/* insert collection row com.wholefoods.ittoolkit.ws.ccf.Request.comments */ insert into ITTOOLKIT.CR_COMMENT (REQ_ID, COMMENT_ID, CREATE_TS, SECTION_ID, USER_ID, TEXT) values (?, ?, ?, ?, ?, ?)] java.sql.BatchUpdateException: ORA-01400: cannot insert NULL into ("ITTOOLKIT"."CR_COMMENT"."CREATE_TS") -- 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
11
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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2007