[Hibernate-JIRA] Created: (HHH-3892) Improve support for mapping SQL LONGVARCHAR and CLOB to Java String, SQL LONGVARBINARY and BLOB to Java byte[]
by Gail Badner (JIRA)
Improve support for mapping SQL LONGVARCHAR and CLOB to Java String, SQL LONGVARBINARY and BLOB to Java byte[]
---------------------------------------------------------------------------------------------------------------
Key: HHH-3892
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3892
Project: Hibernate Core
Issue Type: Improvement
Components: core
Reporter: Gail Badner
Assignee: Gail Badner
Fix For: 3.2.x, 3.3.x, 3.5
Property types will be provided to enable an application to process data for a java.sql.Types.LONGVARCHAR or java.sql.Types.CLOB column as a Java String. Hibernate will internally process the data as a streams. On a read, stream data will immediately be materialized into a Java string.
text - property type to map java.sql.Types.LONGVARCHAR column data as a Java String (via org.hibernate.type.TextType);
(NOTE: currently, org.hibernate.type.TextType incorrectly maps "text" to java.sql.Types.CLOB; this will be fixed by this issue and updated in database dialects)
materialized_clob - property type to map java.sql.Types.CLOB column data as a Java String (via org.hibernate.type.MaterializedClobType);
In addition, new property types will be provided to enable an application to process data for a java.sql.Types.LONGVARBINARY or java.sql.Types.BLOB column as Java byte[]. Hibernate will internally process the data as a streams. On a read, stream data will immediately be materialized into a Java byte[].
image - property type to map java.sql.Types.LONGVARBINARY column data as byte[] (via org.hibernate.type.ImageType);
materialized_blob - property type to map java.sql.Types.BLOB column data as byte[] (via org.hibernate.type.MaterializedBlobType);
--
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
[Hibernate-JIRA] Created: (HHH-4555) Support use of Envers with Auto-commit mode.
by Kevin Schmidt (JIRA)
Support use of Envers with Auto-commit mode.
--------------------------------------------
Key: HHH-4555
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4555
Project: Hibernate Core
Issue Type: New Feature
Components: envers
Affects Versions: 3.5.0-Beta-2
Environment: Hibernate 3.5.0-Beta-2
Reporter: Kevin Schmidt
Currently Envers is designed so that it synchronizes with the currently running transaction in order to know when to commit the inserts into the Audit Tables. This is an effective strategy for ensuring that the audit information is only saved to the database if the Transactional Unit of Work which caused the audit data to be created is committed.
This design creates a limitation on Envers such that it cannot persist audit information unless there is an active transaction. This effectively disables auditing for anyone modifying data using Hibernate outside of a Hibernate Transaction. Specifically, if you are using Autocommit = True and manually flushing the Hibernate Session then you cannot have any of your data audited using Envers.
I am not that well versed with the design of Envers but was hoping this situation could be detected and avoided. Maybe the audit information could be synchronized on the flush event rather than when a transaction is committed to the database.
--
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
[Hibernate-JIRA] Created: (HHH-3383) QueryKey is storing references to entities instead of identifiers
by Manuel Dominguez Sarmiento (JIRA)
QueryKey is storing references to entities instead of identifiers
-----------------------------------------------------------------
Key: HHH-3383
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3383
Project: Hibernate3
Issue Type: Improvement
Components: caching (L2)
Affects Versions: 3.3.0.CR1
Environment: ehcache 1.5.0b2
Reporter: Manuel Dominguez Sarmiento
Context: query caching
Hibernate is storing full entity references when building QueryKeys and the query has restrictions which reference entities. This happens either with Criteria or HQL queries.
Although this is not incorrect, when the referenced entities reference in turn "heavy" object graphs, this causes a very significant memory usage increase, since references to detached entities will remain in the cache. This is even more evident when using disk persistence with ehcache, since the full object graphs are serialized to disk.
This could be easily improved (correct me if I'm wrong) by storing ONLY entity identifiers in the QueryKey instead of full entities, since all the query really needs is the identifier property. The memory usage would decrease dramatically.
So far the workaround we've found is explicitly using restrictions that reference identifiers instead of properties in HQL queries, however this is not particularly elegant, and still leaves open the issue with Criteria queries. The same cannot be done without criteria.createCriteria() which generates an unnecessary join in most cases.
--
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
[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, 9 months
[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, 9 months
[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, 9 months
[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, 9 months
[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, 9 months