Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of mike.vallender@uk.ibm.com
 designates 194.196.100.161 as permitted sender)
To: users@openjpa.apache.org
MIME-Version: 1.0
Subject: Serializing database tables to file - eager load problems    
From: Mike Vallender <mike.vallender@uk.ibm.com>
Message-ID: 
 <OF205E73AC.9092B4A5-ON802576E0.005C382A-802576E0.005FF951@uk.ibm.com>
Date: Mon, 8 Mar 2010 17:33:35 +0000
Content-Type: multipart/alternative;
 boundary="=_alternative 005FF488802576E0_="

--=_alternative 005FF488802576E0_=
Content-Type: text/plain; charset="US-ASCII"

We're have a project where we're using openJPA to store objects in the DB. 
Part of the requirements of the project is that we can export the contents 
of the database to a file (export) and use the file to load up the 
database as well (import). We've written a utility - which does this but 
am having problems with performance. 

The utility basically scans each database table - and for each row 
returned - will output the contents of each property of the associated 
persistent entity. Basic java types just get written out directly. 
References to other persistent entities are dealt with by writing out the 
primary key of the related persistent entity - and arrays of persistent 
objects are just written out as arrays of the primary keys of the objects. 


The performance problem comes from writing out the references to other 
objects. What would be ideal is that if object A is in a one-to-one 
relationship with object B (A has a foreign key to B) then I'd like to 
write the foreign key out - but I can't access the foreign key directly. 
So instead, as said before - we use the primary key of the related object. 
This means that to write an A object out we have to load the B object as 
well in order to get it's primary key.  We used to use lazy loading 
thoughout - and performance was terrible. I just changed things to 
determine which properties of an object are persistent entities and add 
them to an eager parallel fetch group. Performance is fantastic now - but 
doesn't always work. 

Now it seems that if B has a property which is also defined to be eager 
loaded - then when I load data from the A table - there's a join from A-B 
- but also a join from B-C. I'm not interested in the C objects so I set 
maxFetchDepth(1) expecting that only the B objects would be loaded - but 
still C's are being loaded too. 

So the question is  - is there a way to stop the C objects being loaded if 
maxFetchDepth(1) doesn't appear to do it. Is there a way to specify that C 
should be loaded rather than eager loaded (the per field fetch 
configuration adds properties to an eager fetch - I can't see a way to 
exclude items from an eager fetch - or set them to lazy at runtime). Also 
- C's being loaded is not just a performance problem - if the C's are 
loaded - I run into OPENJPA-1508 (where the workaround is to set the 
object to lazy load). 

Regards

Mike 

Michael Vallender
Software Engineer
IBM
Business Analytics - Cognos Software


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--=_alternative 005FF488802576E0_=--