Hi, Amro! Seems interesting! What are you doing exactly? Are you still using ReLinq?
RP On Thursday, December 11, 2014 7:02:48 AM UTC, Amro El-Fakharany wrote: > > 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>: >> >>> 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>: >>> >>>> 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. >>>> 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. >>> >> >> -- --- 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.