Hello, actually I would like to learn how the FetchMode.JOIN is supposed to work in case of cycles (not really cycles but MetamodelGraphWalker considers them cycles).
Check the test case please - it gets LazyInitializationException on a relation despite that relation being marked as JOIN FETCH in the fetch profile. How is this intended to work? Is it a problem of MetamodelGraphWalker and its cycle detection? Or is it planned limitation of FetchMode.JOIN? I can help to fix this, but in order to do that I need to know how this is expected to work. Please disregard EAGER. I only mentioned FetchType.EAGER because I noticed it can cope with the same cyclic relations - and yes, you are right, those are fetched in subsequent selects. But we can't use EAGER (performance reasons). Thank you Vladimir On 06/07/2016 03:05 PM, Steve Ebersole wrote: > There is a huge difference in join-fetch and what we detail for > "EAGER". Join-fetch is also an eager fetch. There are 2 pieces of > information in regards to fetching: when, how? > > EAGER merely describes when: now. > > What you describe as "EAGER" is really a N+1 fetch. So the relation > is fetched immediately, but as "subsequent select". A join-fetch is > still EAGER, but now the relation is fetch via join in the initial > query. Very different behavior. > > On Tue, Jun 7, 2016 at 4:38 AM Vladimir Martinek <v...@sykora.cz > <mailto:v...@sykora.cz>> wrote: > > HHH-10745, runnable test case attached to that issue > (org.hibernate.test.fetchprofiles.cycle.tar.gz). > > Thank you > > Vladimir > > > > On 06/07/2016 06:00 AM, Gail Badner wrote: > > Please create a Jira issue and attach a runnable test case. > > Thanks, > > Gail > > > > On Thu, Jun 2, 2016 at 5:45 AM, Vladimir Martinek <v...@sykora.cz > <mailto:v...@sykora.cz> > > <mailto:v...@sykora.cz <mailto:v...@sykora.cz>>> wrote: > > > > Fetch profiles fail to load certain relations because of > invalid cycle > > detection in MetamodelGraphWalker. Below is an example. > > > > I have compared the behaviour of Fetch Profiles and standard > EAGER > > relations (EAGER does not suffer from this problem). The > > MetamodelGraphWalker graph walker produces the same results, the > > SQL is > > the same (missing relation). > > > > With EAGER the relation is loaded in second pass, via > > SessionImpl.internalLoad(). There it is decided what LoadType is > > used - > > for eager it uses INTERNAL_LOAD_EAGER, for lazy > INTERNAL_LOAD_LAZY. It > > does not take into account the fetch profiles here! > > > > The last place I can get hold of fetch profiles in in > > AbstractLoadPlanBasedEntityLoader line 82. After that the fetch > > profile > > information is lost, never making it anywhere near to > > SessionImpl.internalLoad(). > > > > I would like to implement this, but to do that, I need > someone to > > point > > me in the right direction. Most of all I need answers to > following > > questions: > > > > 1) Is it right to assume the fetch profiles should be > evaluated in > > SessionImpl.internalLoad() and appropriate LoadType used when > > detected a > > relation affected by a fetch profile? > > 2) If so, what is the intended way of getting the fetch profile > > information to SessionImpl.internalLoad()? > > > > Also, a colleague of mine attempted to implement > FetchType.SELECT > > fetch > > strategy and ended up with precisely the same problem. I believe > > solving > > my issue would pave way for quick FetchType.SELECT > implementation > > (which > > we could also use on our project). > > > > > > Thank you > > > > Vladimir Martinek > > > > > > Example: > > > > Have 5 entities - Start, Via1, Via2, Mid and Finish with > following > > relations (all LAZY): > > > > Start n:1 Via1 n:1 Mid n:1 Finish > > Start n:1 Via2 n:1 Mid n:1 Finish > > > > Now, trying to use Fetch Profiles to load Start entity and > all of its > > relations. I would expect Hibernate to execute following SQL > select: > > > > SELECT * FROM Start s > > LEFT OUTER JOIN Via1 v1 (path Start-Via1) > > LEFT OUTER JOIN Mid > > JOIN Finish > > > > LEFT OUTER JOIN Via2 (path Start-Via2) > > LEFT OUTER JOIN Mid > > JOIN Finish > > > > Unfortunately, ii ompletely omits the second join from Mid > to Finish, > > what I am getting is: > > > > SELECT * FROM Start s > > LEFT OUTER JOIN Via1 v1 (path Start-Via1) > > LEFT OUTER JOIN Mid > > JOIN Finish > > > > LEFT OUTER JOIN Via2 (path Start-Via2) > > LEFT OUTER JOIN Mid > > > > I dug deeper into this and found cycle detection in > > MetamodelGraphWalker, line 144. Basically, when > MetamodelGraphWalker > > detects a relation that has already been visited, it > considers it a > > cycle. But in my case it is not a cycle - I just came to the > same > > relation twice using two different paths. > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > <mailto:hibernate-dev@lists.jboss.org> > <mailto:hibernate-dev@lists.jboss.org > <mailto:hibernate-dev@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > -- > > *Ing. Vladimír Martinek* > Programmer > > T: +420 723 908 968 > @: v...@sykora.cz <mailto:v...@sykora.cz> > > Sykora Data Center s.r.o. > 28. října 1512/123, 702 00 Ostrava > www.sykora.cz <http://www.sykora.cz> > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- *Ing. Vladimír Martinek* Programmer T: +420 723 908 968 @: v...@sykora.cz Sykora Data Center s.r.o. 28. října 1512/123, 702 00 Ostrava www.sykora.cz _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev