BlazeDS - n:m relation with eager loading - recursion?

Question

Hello to all!
I have a n:m relation and I do eager loading with Hibernate (and other relations with 1:n and n:m, but not displayed here):
@ManyToMany(fetch=FetchType.EAGER)
    @JoinTable(name = "Group_User",
        joinColumns = {@JoinColumn(name="group_id", referencedColumnName="id")},
        inverseJoinColumns = {@JoinColumn(name="user_id", referencedColumnName="id")}
@Fetch(FetchMode.SELECT)
private List<User> users;
@ManyToMany(mappedBy="users", fetch=FetchType.EAGER)
@Fetch(FetchMode.SELECT)
private List<Group> groups;
So one user can have several groups and in one group can be several users.
So, but now I get all groups in Flex frontend and so I have also all users included, but the problem is, I get a kind of recursion here.
Debugging it and take a look at the groups, I see the users listed, and the user have groups, and these groups have users and so on and so on...
What shoud I do to solve this problem?
Thanks a lot in advance & Best Regards PHANTOMIAS

Answer 1

Abe, Any chance you could publish the answer on the newsgroup?
This was my support response:
I assume each child object is the same type as its parent? That is, you have a
class C with a
member of type Collection<C>?
In that case, consider what putting this member (let's call it M) in the
active fetch groups
does. When loading a C instance, M must be loaded. But if M is full of additional C
instances, then M must be loaded for all of those instances as well, since M is
in the active
fetch groups. And so forth. Thus, eager loading doesn't work very well when the
relation is
of the same type as the target object, because it causes a large recursive process.
SolarMetric has worked to make sure that JDO 2 fetch groups will allow for
specifications of
fetch depths and other advanced features. Until then, however, I'm afraid that
this is a
limitation of Kodo. I'm not sure how deep into your tree structure you want to
go, but you
might consider creating one or more Queries. For example, if you want children and
grandchildren, create one Query for all grandchildren, and one Query for all
children.
Execute both queries. Then going from a grandchild to its parent (I assume
there is a
relation from an object to its parent) won't cause any additional DB hits, since
the children
(the parents of the grandchildren) will already all be in cache. Similarly,
going from a child to
the root object might cause 1 additional DB hit if the root isn't already in
cache, but going
from subsequent children to the root will be satisfied from cache. Or if you
have multiple
roots, consider executing an additional Query for those roots. So in general,
you can fetch N
levels of the tree in N queries, and all relation traversals between those
levels will then be
satisfied from cache.