Re: Unecessary database update?

2014-03-25 Thread Alain Brazeau
Hi Rick,

As requested, here is a test I wrote in the 'openjpa-persistence-jdbc'
project:


package org.apache.openjpa.persistence.jdbc.update;

import java.util.Date;

import javax.persistence.EntityManager;

import org.apache.openjpa.persistence.test.SingleEMFTestCase;


public class TestCascadePersist extends SingleEMFTestCase {

public void setUp() throws Exception {
super.setUp(CLEAR_TABLES, Parent.class, Child.class); 
}


public void testAddChildShouldNotUpdateParent() {
EntityManager em = emf.createEntityManager();

em.getTransaction().begin();
Parent parent = new Parent();
parent.setName(parent);
em.persist(parent);
em.getTransaction().commit();

long parentId = parent.getId();
Date expectedLastModifiedDate = parent.getLastModifiedDate();

em.getTransaction().begin();
parent = em.find(Parent.class, parentId);
parent.newChild(child);
em.getTransaction().commit();

Date actualModifiedDate = parent.getLastModifiedDate(); 

assertEquals(The last modified date should not change.,
 expectedLastModifiedDate.getTime(),
actualModifiedDate.getTime());
}

}


In order for the test to work, the following instance variable and methods
have to be added to the
existing org.apache.openjpa.persistence.jdbc.update.Parent class:


private Date lastModifiedDate;

public Date getLastModifiedDate() {
return lastModifiedDate;
} 

@PrePersist
@PreUpdate
public void onUpdate() {
this.lastModifiedDate = new Date();
} 


Thanks!

Alain



--
View this message in context: 
http://openjpa.208410.n2.nabble.com/Unecessary-database-update-tp7586121p7586153.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.


OpenJPA retrieving one column a seperate select

2014-03-25 Thread mxvs
Hello, I've been using OpenJPA 2.1.2 (JPA 2.0) to retrieve data from a table
called LOGISCHRAPPORT which has about 28 columns. In some cases OpenJPA
decides to issue seperate select statements for one of the columns for no
particular reason, leading to a dramatic decrease in query performance.


Initially everything goes fine and all my columns are retrieved in a
performant, single SELECT statement by JPA.

As soon as I add a relationship to another entity called RAPTAALMETADATA

@OneToMany(fetch=FetchType.EAGER, cascade = CascadeType.ALL)
@JoinColumns({
@JoinColumn(name = RAPPORTNR, referencedColumnName = RAPPORTNR),
@JoinColumn(name = RAPPORTTYPE, referencedColumnName =
RAPPORTTYPE) })
private ListRaptaalmetadata raptaalmetadata;
--- 
Queried using Criteria API as follows:
---
JoinLogischRapport, Raptaalmetadata metadata = reportRoot.join(
raptaalmetadata);

JPA no longer includes one of my original columns called REPORT_COMMENTS
instead it is issuing separate select statements to retrieve the
REPORT_COMMENTS column for each instance of LOGISCHRAPPORT. All other
columns (including the ones coming from RAPTAALMETADATA are retrieved
properly as part of the intial SELECT.

REPORT_COMMENTS is of the HUGEBLOB type in Oracle and I've mapped in in my
Entity as follows:

@Lob
@Basic
@Column(name = REPORT_COMMENTS)
private byte[] reportComments;

I now get tons of these:

SELECT t0.REPORT_COMMENTS 
FROM dwhsd001.LogischRapport t0 
WHERE t0.rapportnr = ? AND t0.rapporttype = ? 
[params=(long) 1473, (String) RAP]

Additionally: as soon as I remove the fetch=FetchType.EAGER attribute from
the @OneToMany annotation described above I start seeing the exact same
behavior for the relationship as I've been getting for the REPORT_COMMENTS
column. This means I'm also getting separate SELECT statements for
retrieving the entity relationship on top of the seperate selects for the
column thereby further degrading performance.

In other words I'm then also getting tons of these:

SELECT t0.isotaalcode, t0.rapportnr, t0.rapporttype, 
t0.FUNCDESC_MODIFIED_BY, t0.FUNCDESC_MODIFIED_DATE, 
t0.FUNCTIONAL_DESCRIPTION, t0.omschrijving, t0.titel 
FROM dwhsd001.Raptaalmetadata t0 
WHERE t0.rapportnr = ? AND t0.rapporttype = ? 

Its not a LAZY loading problem as I've specifically tested that case. I
don't see any other reason why OpenJPA decides to retrieve this one column
using separate statements.

Can anyone point out why I might be seeing this behavior and how I can avoid
it?



--
View this message in context: 
http://openjpa.208410.n2.nabble.com/OpenJPA-retrieving-one-column-a-seperate-select-tp7586156.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.