openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henno Vermeulen <he...@huizemolenaar.nl>
Subject RE: Fetchgroups recursion problem
Date Tue, 13 Nov 2012 17:22:57 GMT
I added OpenJPA test cases to https://issues.apache.org/jira/browse/OPENJPA-2296 that show
the bug (TestRecursiveEagerSQL.java).

The N+1 select problem also occurs for ManyToOne when we only have two entities. E.g. A OneToMany
B and when the ManyToOne relation from B to A is eager and we select B: then for each B it's
A is loaded using a separate query, see TestManyOneEagerSQL.java. For A OneToOne B the problem
does not occur, see TestOneOneEagerSQL.java. 

I also found a partial fix: it can be fixed for the parallel eager select strategy by having
RelationFieldStrategy.selectEagerJoin not limit recursive eager fetching to JOIN. I ran all
tests in persistence-jdbc and it does result in the existing TestManyEagerSQL failing with
duplicates in the list, perhaps this can be fixed using DISTINCT? (TestJPQLSubquery also fails
but only because it is too sensitive to the generated SQL and is easily adjusted). 

The join eager select strategy is not used at JDBCStoreManager.createEagerSelects because

 - boolean hasJoin = fetch.hasJoin(fms[i].getFullName(false)); is false 
 - inEagerJoin = true (select query already has an eager to-one join) 

I do not know if this can be fixed as well. 

Finally a workaround can be done by using cached entities in the entity manager context. Simply
select all entities that are otherwise loaded by their id as in the "load field" trace. 
For the Company - Employee - Project example this would mean performing the query "SELECT
e FROM Employee e" before the actual query.

So for Sirisha's problem selecting all B objects that would be returned inside the object
graph return by the query for A could solve the problem.

Mime
View raw message