[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
13 years
[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
13 years
[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
13 years
[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
13 years
[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
13 years
[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
13 years
[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
13 years