Re: Problems with extra N+1 requests - likely due to poor mapping defns, but not sure how to rectify


ebenzacar@...
 

Thanks Andy.  Fair enough (embedded vs related).

I forgot to mention the fetch-groups.  Indeed, I have no fetch groups explicity defined - either in the mapping file nor in the API usage.  Everything is using the default fetch group.
But based on your explanation and rereading the DN docs for the N-teenth time, https://www.datanucleus.org/products/accessplatform_5_2/jdo/persistence.html#fetch_groups it clearly identifies that the default fetch group is essentially primitive+ values (ie: int, String, BigDecimal, Date, etc).  So I didn't have any expectation that the Related Objects will be loaded as part of the default fetch group (particularly with maxDepth =1), but was hoping/expecting that at least the FK references would be loaded at the same time to avoid the extra +1 calls just to retrieve the FK values.  

Reading the Kodo docs for the same background, I now see the difference.  In Kodo, they clearly indicate that the object will be left out of the fetch-group, but the FK will be loaded for it.  Whereas in DN, it seems that if the object isn't explicitly added to the fetch-group, the FK will be skipped as well.

I have now added the "addPerson" and "modPerson" to the default-fetch-group, and defined my maxDepth as 1.  And seems to work more inline with expectations.

Thanks,

 

Eric



I'm okay with the extra queries to retrieve the "addPerson" and "modPerson", but don't want the extra DB hit to retrieve their FK values independently.

Is there a way I can configure the defaultFetchGroup to "preload" the FKs during the initial object fetch, without identifying that I want the full objects loaded each time?

Thanks,

Eric

 

Join main@datanucleus.groups.io to automatically receive all group messages.