FYI, I reported the issue (generating both wrong, exception-throwing SQL as well as the less pressing problem of suboptimal behaviour) on JIRA as NH-3616 <https://nhibernate.jira.com/browse/NH-3616>. Will be grateful if someone could have a look and comment on whether I can be of any further help in fixing this.
On Friday, May 16, 2014 1:00:14 PM UTC+2, Dawid Ciecierski wrote: > > 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.
