openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "C N Davies" <...@cndavies.com>
Subject RE: Serializing database tables to file - eager load problems
Date Mon, 08 Mar 2010 17:51:30 GMT
Hi Mike,

I had a similar issue when creating my reporting engine, since I always use
single table per class strategy I and a consistent foreign key name, I
reverted to native queries to extract the data. For example, I have a main
entity "Supplier" which has a ManyToOne relationship to the "User" Entity.
Both entities have a unique key called "uniqueid", OpenJPA therefore creates
a column in the Supplier tables named user_uniqueid.  So I just used native
SQL to extract the data for my reports.

Just my 2c

Chris





-----Original Message-----
From: Mike Vallender [mailto:mike.vallender@uk.ibm.com] 
Sent: Tuesday, 9 March 2010 4:34 AM
To: users@openjpa.apache.org
Subject: Serializing database tables to file - eager load problems 

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







Mime
View raw message