May 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5659) Problem using Hibernate3.6.0.Final with CLOB field in Oracle.

by Samuel Rettore (JIRA)

Problem using Hibernate3.6.0.Final with CLOB field in Oracle. ------------------------------------------------------------- Key: HHH-5659 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5659 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.0 Environment: Hibernate 3.6.0.Final, Database Oracle10G on Linux X64, and JPA Reporter: Samuel Rettore Priority: Minor When migrating my project that works well with Hibernate 3.5.6 End-to 3.6.0.Final the Clob field displays the following error |java.lang.ClassCastException: $Proxy1119 cannot be cast to oracle.sql.CLOB at oracle.jdbc.driver.OraclePreparedStatement.setClob(OraclePreparedStatement.java:7021) at org.hibernate.type.descriptor.sql.ClobTypeDescriptor$1.doBind(ClobTypeDescriptor.java:60) at org.hibernate.type.descriptor.sql.BasicBinder.bind(BasicBinder.java:89) at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:282) at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:277) at org.hibernate.type.AbstractSingleColumnStandardBasicType.nullSafeSet(AbstractSingleColumnStandardBasicType.java:85) at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:2166) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2412) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2856) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:79) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:273) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:184) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216) at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:795) at com.sun.enterprise.container.common.impl.EntityManagerWrapper.flush(EntityManagerWrapper.java:407) --- This error appears only with CLOB field. to get more information at their disposal. Thanks Rettore. -- 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

13
44
0 / 0

[Hibernate-JIRA] Created: (HHH-5862) ClassCastException overriding with a new Set a existing collection.

by Francisco Philip (JIRA)

ClassCastException overriding with a new Set a existing collection. ------------------------------------------------------------------- Key: HHH-5862 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5862 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.0 Environment: testcase, java6, windows Reporter: Francisco Philip Any idea? java.lang.ClassCastException: java.util.HashSet cannot be cast to org.hibernate.collection.PersistentCollection at org.hibernate.event.def.FlushVisitor.processCollection(FlushVisitor.java:57) at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:122) at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:83) -- 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

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2896) unified approach for id and natural-id loading

by Steve Ebersole (JIRA)

unified approach for id and natural-id loading ----------------------------------------------- Key: HHH-2896 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2896 Project: Hibernate3 Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole A follow-on to HHH-2879 in regards to unifying the loading of entities by pk or natural-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, 8 months

3
21
0 / 0

[Hibernate-JIRA] Created: (HHH-5275) Criteria.setLockMode does not work correctly

by Björn Moritz (JIRA)

Criteria.setLockMode does not work correctly -------------------------------------------- Key: HHH-5275 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.2 Environment: Hibernate 3.5.2, Oracle 10 (using org.hibernate.dialect.Oracle10gDialect Reporter: Björn Moritz Priority: Minor Attachments: TestCase.zip The LockMode set via Criteria.setLockMode does not generate a ' for update' SQL statement. In the org.hibernate.dialect.Dialect class only the LockOptions are used for determining a possible addition to the SQL statement if using pessimistic locking. This behaviour is different from Hibernate 3.1.3. In the supplied TestCase two threads are reading the same database record; one of those threads should use pessimistic locking thereby blocking the other thread. But both threads can read the database record causing the test to fail. -- 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

8
43
0 / 0

[Hibernate-JIRA] Created: (HHH-2763) (lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush()

by S.Schnabl (JIRA)

(lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush() -------------------------------------------------------------------------------------------------------- Key: HHH-2763 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5, 3.2.4.sp1 Environment: Windows-XP, Jboss 4.2.1GA, Hibernate 3.2.4SP1, EJB3 Reporter: S.Schnabl Priority: Critical Attachments: Testcase.zip For more details see the attached testcase. I'm sorry, but in the short of time i only got a testcase for jboss-server 4.2. Please deploy the server.ear from /release-directory and then call the /src/client/TestCaseClient.java. [Summarized] It seems, that touching a lazy (Persistent-)Collection of at least a m:n relation inside a Hibernate event-listener always raises this error: org.hibernate.AssertionFailure: collection [n-side] was not processed by flush() [Explanation] I have two entities A. and B. Both having a m:n relation between each other. Furthermore there is an PostUpdateListener, which iterates onUpdate of entitiy through all properties of updated entity. [Testcase] Both entities are linked with eachother (m:n). If i now do a simple update of a property of entity A --> MyPostUpdateListener will be called, which iterates through every property of the updated entity. In case of this property was a collection (= lazy PersistentCollection of m:n relation), hibernate initializes the collection for further work. I can now run through all objects of the collection, but after all work is done in listener, I get the following exception from postFlush: Caused by: org.hibernate.AssertionFailure: collection [com.qualitype.testcase.server.ejb.entity.EntityB.entitiesOfA] was not processed by flush() at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:205) at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:333) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:28) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:515) ... 29 more Attention: EntityB.entitiesOfA is the other-side collection of the m:n relation of the updated EntityA. We are using hibernate-event listener system for auditing-purposes, so you should understand that touching every (element in the) collection is necessary for audit-purposes. Seems for me like a serious bug. Need this fixed asap ... -- 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

32
59
0 / 0

[Hibernate-JIRA] Created: (HHH-4439) In general it is impossible to override properties defined in @MappedSuperclass to change how they will be handled during auditing.

by Eugene Goroschenya (JIRA)

In general it is impossible to override properties defined in @MappedSuperclass to change how they will be handled during auditing. ----------------------------------------------------------------------------------------------------------------------------------- Key: HHH-4439 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4439 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.5.0.Beta-1, 3.3.2, 3.2.x, 3.5 Reporter: Eugene Goroschenya Priority: Critical It seems there are several use cases with this issue but most important for me is @MappedSuperclass class A { @Audited private String value; } @Entity @Audited class MyAutided extends A { } @Entity class MyNotAutided extends A { } I need MyNotAutided is not audited at all (there is not MyNotAutided_AUD table and MyNotAutided revisions are not created) nut seems it is impossible because use case above leads to creating MyNotAutided_AUD table and creating of revisions for MyNotAutided. I assume @AuditOverride must support it to say that MyNotAutided.value is not audited but it doesn't work. -- 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

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5891) AuditReaderImpl.getRevisions result is not ordered as specified in Javadoc

by Thierry Monney (JIRA)

AuditReaderImpl.getRevisions result is not ordered as specified in Javadoc -------------------------------------------------------------------------- Key: HHH-5891 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5891 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.6.1 Reporter: Thierry Monney The Javadoc of org.hibernate.envers.AuditReader.getRevisions specifies that results are {quote} sorted in ascending order (so older revisions come first)??. {quote} The implementation in {{org.hibernate.envers.reader.AuditReaderImpl}} is as follows: {{return createQuery().forRevisionsOfEntity(cls, entityName, false, true).addProjection(AuditEntity.revisionNumber()).add(AuditEntity.id().eq(primaryKey)).getResultList();}} The Javadoc of {{AuditQueryCreator.forRevisionsOfEntity}} specifies that {quote} The results of the query will be sorted in ascending order by the revision number, unless an order or projection is added {quote} Since the implementation adds a projection on the revision number, no ordering is performed, which causes randomly ordered results to be returned. The fix looks simple: just replace the above code with {{return createQuery().forRevisionsOfEntity(cls, entityName, false, true).addProjection(AuditEntity.revisionNumber()).add(AuditEntity.id().eq(primaryKey)).addOrder(AuditEntity.revisionNumber().asc()).getResultList();}} -- 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

5
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5257) @JoinTable results in redundant join in the generated SQL

by Sharath Reddy (JIRA)

@JoinTable results in redundant join in the generated SQL --------------------------------------------------------- Key: HHH-5257 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5257 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.2 Reporter: Sharath Reddy Priority: Minor Fix For: 3.6 Attachments: testcase.zip An Account can have several Clients: @Entity @Table(name = "CLIENT") public class Client implements Serializable { private String street; private String code; private String city; @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private int id; @ManyToOne @JoinTable(name = "CLIENT_ACCOUNT", joinColumns = {@JoinColumn(name = "FK_CLIENT", referencedColumnName = "ID")}, inverseJoinColumns = {@JoinColumn(name = "FK_ACCOUNT", referencedColumnName = "ID")}) private Account account; ..... } @Entity @Table(name = "ACCOUNT") public class Account implements Serializable { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private int id; private String number; private double balance; @OneToMany (fetch = FetchType.EAGER, mappedBy="account") private Set<Client> holders; ... } When we load the Account entity: Account a1 = (Account) session.load(Account.class, accountId); We see that there is a redundant join at the end - from the CLIENT table to the CLIENT_ACCOUNT table: select account0_.id as id2_1_, account0_.balance as balance2_1_, account0_.number as number2_1_, holders1_.FK_ACCOUNT as FK1_2_3_, client2_.id as FK2_3_, client2_.id as id0_0_, client2_.city as city0_0_, client2_.code as code0_0_, client2_.street as street0_0_, client2_1_.FK_ACCOUNT as FK1_1_0_ from ACCOUNT account0_ left outer join CLIENT_ACCOUNT holders1_ on account0_.id=holders1_.FK_ACCOUNT left outer join CLIENT client2_ on holders1_.FK_CLIENT=client2_.id left outer join CLIENT_ACCOUNT client2_1_ on client2_.id=client2_1_.FK_CLIENT where account0_.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, 8 months

5
22
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, 8 months

6
11
0 / 0

[Hibernate-JIRA] Created: (HHH-6063) The fix for HHH-5126 breaks array constructor in PostgreSQL

by Jon Vincent (JIRA)

The fix for HHH-5126 breaks array constructor in PostgreSQL ----------------------------------------------------------- Key: HHH-6063 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6063 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 4.0.0.Alpha1, 3.6.2, 3.6.1 Environment: PostgreSQL, any version Reporter: Jon Vincent The fix for HHH-5126 supports this JPA2-compliant IN query: {{{ SELECT * FROM my_table WHERE id IN :collection }}} Before HHH-5126 was fixed, Hibernate required the developer to surround collection-valued parameters with parentheses: {{{ SELECT * FROM my_table WHERE id IN (:collection) }}} The implemented fix was simply to output parentheses in the generated SQL. Unfortunately, this breaks _other_ uses of collection-values parameters, such as for arrays in PostgreSQL: {{{ CREATE TABLE my_table (some_array INTEGER[]); INSERT INTO my_table (some_array) VALUES (ARRAY[:collection]); }}} Is there a way to turn off the fix for HHH-5126? For us, at least, the old code was more flexible and allowed access to important database features. -- 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

3
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues May 2011