Hi Ricardo! I unfortunately had to stop a while ago so I’m not doing anything right now.
My Intention was to translate Linq directly to SQL using the appropriate dialect for each and every single bit of sql text. As for ReLinq: No, I didn’t use it. Amro Von: nhibernate-development@googlegroups.com [mailto:nhibernate-development@googlegroups.com] Im Auftrag von Ricardo Peres Gesendet: Donnerstag, 11. Dezember 2014 12:49 An: nhibernate-development@googlegroups.com Betreff: Re: [nhibernate-development] Could the future hold a bit of simplification? 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 <mailto: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 <mailto: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 <mailto:nhibernate-development+unsubscr...@googlegroups.com> nhibernate-development+unsubscr...@googlegroups.com. For more options, visit <https://groups.google.com/d/optout> 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 <mailto:nhibernate-development+unsubscr...@googlegroups.com> 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 <mailto: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.
