Re: Serializing database tables to file - eager load problems

[Michael Dick <mi...@gmail.com>]

Hi Mike,

Seems like a problem with MaxFetchDepth.

You should be able to use FetchPlan.removeField() to prevent C from being
eagerly loaded. Something like this maybe:

OpenJPAQuery q = em.createQuery("SELECT a from A where ...");
q.getFetchPlan().addField(A.class, "b");
q.getFetchPlan().removeField(B.class, "c");
. . .

hth
-mike

On Mon, Mar 8, 2010 at 11:33 AM, Mike Vallender
<mi...@uk.ibm.com>wrote:

> 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
>
>
>
>
>
>