Description
Daniel Guenter created an issue — 20th April 2011, 9:27:32:
The linq provider caches a query assuming that ALL constants will be turned into HQL parameters. Sometimes this is not the case. A linq extension that selects a concrete entity property based on a constant value will never pass that value into HQL.
Daniel Guenter added a comment — 20th April 2011, 9:40:52:
You will have to import the files into the project.
Daniel Guenter added a comment — 20th April 2011, 16:31:26:
I have a patch (HG) which solves this issue.
https://bitbucket.org/nicaog/nhibernate-patches/changeset/8ea3eb358e61
However it does introduce a new concept into the system. IHqlGenerator(s) are allowed to participate in the initial building of the expression tree and key through the use of a SpecialMemberVisitor and a new interface method called Visit. This allows for expression replacing and parameter manipulation before the expression key is finalized.
This solution may be a bit more intrusive than I had hoped it would be. However it does allow for more advanced and intelligent hql generators.
Daniel Guenter added a comment — 29th August 2011, 20:44:55:
I've updated my solution for this issue to include a NhNonParameterExpression that is used to circumvent ConstantExpression(s) and prevent the value from being cached.
This is a systemic problem with NHibernate's linq provider in dealing with any programmatic values that deal with column names.
If there is any interest in this solution, I will go through the work of generating a patch that works against SVN, otherwise you can see the changes at
https://bitbucket.org/nicaog/nhibernate-patches/changeset/0d88bb5862a2
kkozmic added a comment — 8th February 2012, 10:38:38:
Any progress on this issue? I wasted 2h today chasing an issue that was caused by this. How likely is this going to get fixed in vNext?
Oskar Berggren added a comment — 8th February 2012, 10:49:30:
Doesn't this sound a bit like NH-2500?
Oskar Berggren added a comment — 8th February 2012, 17:15:45:
Linking NH-2658 and NH-2500. Not exactly the same, but sort of complementary.
Tamizhvendan S added a comment — 2nd July 2014, 12:32:14:
Any Solutions for this issue ?
Can we add the patch provided by Daniel, Guenter ?
Sÿl added a comment — 22nd April 2015, 9:55:30:
I agree this issue becomes a real problem when optimisations are required.
I reviewed the patch from <~danielg> and it seems quite ok, why this long to react on it?
Alexander Zaytsev added a comment — 9th July 2015, 4:21:52:
Dynamic component part has been fixed as NH-2664