I also share the exact same experience Gunnar and Oskar. Infact a couple of months ago I started a branch for a Linq reimplementation dropping the dependency on HQL: https://github.com/amroel/nhibernate-core/tree/linq_experimental
Also take a look at: http://blogs.msdn.com/b/mattwar/archive/2008/11/18/linq-links.aspx Amro On Thursday, December 11, 2014 12:04:47 AM UTC+1, Gunnar Liljas wrote: > > Thanks for responding, Oskar! > > I have had exactly the same experience with the hidden and inlined method > calls. It's frustrating, to say the least. > > What I'm arguing is that having an antlr parser in the way make no sense > (to me) for a Linq query. The raw expression tree from Linq is a bit tricky > to work with, but ReLinq takes care of most of that (sometimes it takes > care of too much). I believe yet another expression tree could be > necessary, but from there translation to SQL should be more straightforward > than today. I also believe that future SQL "dialects" should be able to get > involved at this stage in the processing, so that they can more efficiently > deal with e.g Skip/Take etc. But they wouldn't have to. > > > Maybe this will be possible: > > HQL Linq > \ / > Antlr4 ReLinq > \ / > Intermediate > \ / > SQL > > Even Criterias and QueryOver could produce the same intermediate tree. > > /G > > > 2014-12-10 23:06 GMT+01:00 Oskar Berggren <oskar.b...@gmail.com > <javascript:>>: > >> There has been some light discussion in the Hibernate mailing list lately >> regarding antlr4, which seems to have a quite different model compared to >> antlr3. According to the postings, it would require a rethinking of how >> (N)Hibernate handles the syntax trees. >> >> One thing that always bugs me is that almost everything important seems >> to happen inside ("through") constructor calls, or sometime inside method >> calls that are written directly as parameters to a constructor call. I find >> myself repeatedly stepping over such code during debugging, only to realise >> I now have to start over because hidden behind that fairly innocent-looking >> new X(y, z, x.GetTranslatorOrWhatever()) was actually the brunt of the >> logic. >> >> The way that several antlr parsers are involved also surprised me >> originally. >> >> /Oskar >> >> 2014-12-10 22:50 GMT+01:00 Gunnar Liljas <gunnar...@gmail.com >> <javascript:>>: >> >>> I'm currently investigating a bit of query functionality in NHibernate >>> and I'm losing all of my hair, since I've ended up in the HqlSqlWalker >>> (there generated code part). >>> >>> I understand why the "new" Linq provider was built on top of the Hql >>> parts, but at the same time it's a part of Nhibernate's code base that I >>> really, really ha......don't like. >>> >>> A Linq expression tree is transformed into a ReLinq query model. >>> The query model is transformed into an intermediate Hql tree >>> The intermediate tree is transformed into "the real" Hql tree >>> The Hql tree is eventually transformed into SQL >>> >>> The performance hit of all this may be neglible, but the complexity hit >>> is insane. There is at least one tree to many and the complexity of the >>> HqlSqlWalker is making it impossible to work with. It's not meant to be >>> worked with, but having core functionality in a black hole is annoying. >>> Going from a ReLinq query model to SQL will always be complex stuff, but it >>> shouldn't have to be this convoluted. >>> >>> At some point I think it would make more sense to reverse the model, so >>> that the Hql is processed into a syntax tree optimized for productive and >>> performant Linq. >>> >>> Thoughts? >>> >>> /G >>> >>> PS. At certain points the HqlSqlWalker calls HandleClauseStart, which >>> sets _currentClauseType, There is no corresponding HandleClauseEnd to pop >>> the state, which means that _currentClauseType can actually be wrong. In >>> my test code that meant that the parser though it was inside a subquery >>> when it actually wasn't any longer. Just an example of the kind of >>> weirdness that is almost impossible to debug, and even harder to do >>> something about once you find the problem. DS >>> >>> >>> -- >>> >>> --- >>> 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 >>> <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> >> --- >> 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 >> <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- --- 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.
