If this is the case, then why do they attempt to honour CollectionFetchMode.Subselect? The HQL and LINQ providers not honouring some of the mappings behaviour does not seem to be mentioned in the documentation.
(I should add that the exception is thrown when using .Skip(X).Take(Y) on the parent entity; with .Take the exception is not thrown, the generated SQL is merely an incorrect attempt at honouring Subselect.) On Friday, May 16, 2014 12:49:15 PM UTC+2, Ricardo Peres wrote: > > This is by design: LINQ and HQL ignore the fetch mode and treat all > references as lazy unless you explicitly fetch the items/collections you > want. > > RP > > On Friday, May 16, 2014 11:25:12 AM UTC+1, Dawid Ciecierski wrote: >> >> Funny that — with further testing of the different querying strategies I >> came across some pretty strange behaviour: configured collection fetch >> strategies honoured only in some cases. >> >> In particular, CreateCriteria<T> works as expected with >> CollectionFetchMode.Subselect and CollectionFetchMode.Join. >> CollectionFetchMode.Join is not honoured by the LINQ provider (Query<T>) >> and HQL (CreateQuery), with both providers behaving as though >> CollectionFetchMode.Select was set. It gets worse with >> CollectionFetchMode.Subselect: both the LINQ and HQL providers produce >> queries that are bad SQL, and their execution results in exceptions. >> >> If I can confirm this with more poking around, I'll try to come up with >> unit tests that demontrate the above later today and raise an issue on JIRA >> in hopes of having this resolved before 4.0 RTMs. >> >> Dawid >> >> On Thursday, May 15, 2014 10:50:48 PM UTC+2, Dawid Ciecierski wrote: >>> >>> Tried setting it before posting, but it does not seem to change >>> behaviour in my tests with NHProf. The enum names suggest that it may be >>> affecting the way FetchMany is *performed* rather than when it is >>> *invoked*. If you think it should be otherwise, I can try and prepare a >>> small sample project. >>> >>> Dawid >>> >>> On Thursday, May 15, 2014 7:10:25 PM UTC+2, Ricardo Peres wrote: >>>> >>>> There's the FetchMode, for which you can specify >>>> CollectionFetchMode.Join. >>>> >>>> RP >>>> >>>> On Thursday, May 15, 2014 5:31:56 PM UTC+1, Dawid Ciecierski wrote: >>>>> >>>>> Hello, >>>>> >>>>> I'm wondering if there is an extensibility point in NHibernate that >>>>> would allow me to force some collections to be eagerly-loaded >>>>> FetchMany-style (via JOINs)? While I do have CollectionLazy set to >>>>> NoLazy, >>>>> my collections are still loaded in separate trips to the database, which >>>>> is >>>>> not very scaleable beyond a few dozen entites. FetchMany works a treat, >>>>> but >>>>> there are places where I would prefer not to have code with >>>>> NHibernate-specific calls. I was thinking along the lines of session >>>>> interceptors, query translators, custom visitors, etc. Had a brief look >>>>> at >>>>> the codebase but not too sure where and what to look for. >>>>> >>>>> (Would I be correct to say that a LINQ query is later translated into >>>>> HQL, and therefore it would be best to transform the HQL rather than just >>>>> the LINQ expression to have maximum coverage — both LINQ and HQL queries?) >>>>> >>>>> Regards, >>>>> Dawid Ciecierski >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers. For more options, visit https://groups.google.com/d/optout.
