Specifying how many "levels" of related entities-attributes to retrieve for an object?

[Matt Duncan]

I've noticed that when retrieving an object from the DB mapperdao only returns the first "level" of related entities-attributes.

For example:

case class Node(someProp: String, childNode: Option[Node])


val thirdNode = Node(someProp: "theThird", childNode: None)

val secondNode = Node(someProp: "theSecond", childNode: ThirdNode)
val firstNode = Node(someProp: "parent", childNode: SecondNode)

If I persist these objects and then retrieve "firstNode" I get this returned

Node(someProp: "parent",
         childNode: Node("theSecond", null)) //I want to have thirdNode loaded as well

It makes sense that you wouldn't load *all* child attributes with relationships because in a situation with a huge graph you'd be loading a huge amount of potentially unnecessary data every time you retrieved a single entity -- however I have a few instances where I need to be able to reach the third "level" of related entity-attributes. I check the QueryConfig setting but, other than MultiThreaded which looks like it just improves performance, I didn't see any options for explicitly setting how many levels to retrieve. Is this something I can achieve with mapperdao?

Thanks for your time!

[Konstantinos Kougios]

Hi Matt,

    In fact mapperdao should retrieve (by default) ALL the graph. QueryConfig can specify the related data you *don't* want to retrieve. Also you can specify what to lazy load.

So it is a surprise that loaded.childNode.childNode == null.

If you have enabled lazy loading ,then when you debug you might see some fields as null. But those should be loaded when code tries to access those.

If you happen to have firstNode.childNode.childNode == firstNode, then this explains it. MapperDao can't load cyclic references (it is not possible to do that for immutable classes without tricks).

Also if you can create the minimum reproducible code for the issue, we can debug it. What does your entity look like?

Cheers

--
You received this message because you are subscribed to the Google Groups "mapperdao" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapperdao+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Duncan]

I think you are correct! I am bumping up against cyclic references. I have

case class Tournament(...,teams: List[Team]..., tourType: TournamentType)
case class Team(...,tournament: Tournament)

I am trying to get 

aTournament.teams.head.tournament.tourType.name

(Here's a screenshot)

I'm falling down my own rabbit hole :) I think I can fix this by querying for Teams (on TeamEntity) and filtering by Tournament.

Follow-up about the cyclic reference: When I view the cyclic reference Tournament (on team.tournament) *some* of its properties (primitives) are populated while others(relationship-related) aren't. What dictates this behavior?

[Konstantinos Kougios]

Hi,

    Regarding the cyclic reference, the story goes that mapperdao tries to avoid reflection (it is used only for lazy loaded data). So when you query for tournaments, mapperdao does the following:

1. gets the tournaments from your Tournament table (only). It creates Tournament instances (A) with that data, ofcourse all references are null.

2. goes recursively to get the Teams. So it instantiates a Team, but uses (A) to fill in team.tournament because still not all required information about the Tournament is available.

3. at #2, it realizes that Tournament (A) would be loaded again (in a never ending loop) if it continued the recursion, so it stops.

Notice that aTournament.teeams.head.tournament.neq(aTournament) (not same instance)

Ofcourse reflection could be used and it would be possible to enhance the library to use reflection if possible, so please feel free to open an enhancement request (or bug fix if you rather think it as a bug).