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> 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>> 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> > > 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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
