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.
