That makes sense. But, I guess I'm asking for alternatives to including subqueries in the FROM clause. Is the idea that all subqueries are somehow promoted to the main query? Is there some overarching "philosophy" I should be following when attempting to do so?
On Tuesday, February 23, 2016 at 10:28:25 AM UTC-6, Oskar Berggren wrote: > > The HQL engine does not support subqueries in the FROM clause, and the > LINQ provider has to work within this limitation. > > /OSkar > > 2016-02-22 22:05 GMT+00:00 Andrew Brobston <abro...@gmail.com > <javascript:>>: > >> I am running into some difficulties as I work on fixing NH-3845 >> <https://nhibernate.jira.com/browse/NH-3845> via Pull Request #456 >> <https://github.com/nhibernate/nhibernate-core/pull/456>, which I badly >> need fixed for a client project. There is an additional test case >> <https://gist.github.com/abrobston/290430f197e60c4addf4> that I would >> add to the fixture >> <https://github.com/abrobston/nhibernate-core/blob/NH3845/src/NHibernate.Test/NHSpecificTest/NH3845/Fixture.cs> >> : >> >> >> [Test] >> public void SourceTypeWhenOfTypeAppliedToSelectIsCorrect() >> { >> using (ISession session = OpenSession()) >> using (session.BeginTransaction()) >> { >> var entityQuery = session.Query<IMainEntity>(); >> var result = >> entityQuery.Where( >> m => >> m.Properties.OfType<IPropertyEntityC>() >> .Select(c => c.AnotherEntity) >> .OfType<AnotherEntity>() >> .Any(ae => ae.Text == "Another Entity Text")).ToList >> (); >> Assert.AreEqual(1, result.Count); >> } >> } >> >> >> The test case fails, of course. One of the reasons this issue is >> difficult to fix is that some part of the Linq provider keeps adding a >> Query node as the first child of a Range node. None of the existing code, >> however, appears to support this scenario: >> >> <http://goog_1033279954> >> PolymorphicQuerySourceDetector.cs >> <https://github.com/nhibernate/nhibernate-core/blob/master/src/NHibernate/Hql/Ast/ANTLR/PolymorphicQuerySourceDetector.cs> >> : >> private static string GetClassName(IASTNode querySource) >> { >> switch (querySource.Type) >> { >> case HqlSqlWalker.IDENT: >> return querySource.Text; >> case HqlSqlWalker.DOT: >> return BuildPath(querySource); >> } >> >> // TODO >> throw new NotSupportedException(); >> } >> >> HqlSqlWalker.g >> <https://github.com/nhibernate/nhibernate-core/blob/master/src/NHibernate/Hql/Ast/ANTLR/HqlSqlWalker.g> >> : >> fromElement! >> @init { >> IASTNode fromElement = null; >> } >> // A simple class name, alias element. >> : ^(RANGE p=path (a=ALIAS)? (pf=FETCH)? ) { fromElement = >> CreateFromElement($p.p, $p.tree, $a, $pf); } >> -> {fromElement != null}? ^({fromElement}) >> -> >> | je=joinElement >> -> //$je >> // A from element created due to filter compilation >> | fe=FILTER_ENTITY a3=ALIAS >> -> ^({CreateFromFilterElement($fe,$a3)}) >> ; >> >> If I had to guess at the design philosophy of subqueries in the Linq >> provider, I would guess that subqueries in the FROM clause are supposed to >> be promoted to the outermost query. I'm not sure of that, however, and it >> isn't clear to me how this goal is accomplished in all cases. >> >> Could someone point me in the right direction? I've tried allowing the >> query node to be the first child of the range node, but I'm not having any >> luck getting my solution to work. >> >> >> -- --- You received this message because you are subscribed to the Google Groups "nhibernate-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to nhibernate-development+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
