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.

Reply via email to