Description
Patrick Earl created an issue — 28th October 2010, 17:58:53:
When doing this, the same query was generated all there times.
int? nullVariable = null;
int? notNullVariable = 1;s.Query().Where(a => a.Data == null).ToList();
s.Query().Where(a => a.Data == nullVariable).ToList();
s.Query().Where(a => a.Data == notNullVariable).ToList();select ... from a a0* where a0*.Data is null
Clearly the last query should not be checking for null entries. When the first two queries are commented out, the last one works fine.
Patrick Earl added a comment — 28th October 2010, 19:02:52:
I meant to say "all three", not "all there".
Patrick Earl added a comment — 31st October 2010, 18:51:59:
NH-2402 fixes this.
Joao Braganca added a comment — 4th November 2010, 13:25:03:
I have a related problem, and I am not sure the patch attached to NH-2402 fixes it.
var exportCorrelationId = GuidCombGenerator.Generate();
var commands = (from report in session.Query()
select new ExportApprovedMeasuresOnSubmittalCommand
{
AggregateId = report.AggregateId,
CorrelationId = exportCorrelationId
}).ToArray();No matter how many times this query is run, the value of command.CorrelationId does not change. I guess it is being cached. Should I create a new issue for this? I am running NH 3 beta 2.
Patrick Earl added a comment — 4th November 2010, 23:14:58:
If you want a new Id, use CorrelationId = GuidCombGenerator.Generate(). Right now you're just assigning the single exportCorrelationId to all results. The Linq provider does seem to work properly if the closure is modified. If you still have problems, I'd suggest creating a test case in a separate issue.
Joao Braganca added a comment — 9th November 2010, 10:38:18:
That is the intended result. All these commands should share the same correlationid. It is when this controller action is called a second time that the old correlationid is used.
Patrick Earl added a comment — 9th November 2010, 10:50:00:
That does sound like a caching issue... can you provide a broken unit test? The NHibernate.Test project has an NHSpecificTest folder that you can put issue related tests into. To run them, you just need to change the App.config to point at a local SQL Server instance.
Joao Braganca added a comment — 12th November 2010, 15:44:06:
Hey, sorry about the long wait, but I finally found the time to repro this. Just so you know, NH-2402 was applied to my working copy and it did not fix this.
Dean Ward added a comment — 1st December 2010, 4:59:32:
Having looked at this code for another problem I'm having it would appear that your issue is definitely related to caching. If there is somebody out there more able to fix it than me, then QueryModelVisitor::VisitSelectClause is worth a look. The 'exportCorrelationId' from Joao's query is a constant in the select expression.
A fix would be to change the HQL produced by SelectClauseVisitor to initialise the member in the projection from the parameter generated by the expression... However a comment in SelectClauseVisitor::CanBeEvaluatedInHqlSelectStatement - '// Hql can't do New or Member Init' - seems to indicate this isn't doable?
Currently the HQL generated contains the constant value and this is then cached as part of the HQL plan higher up the call chain. There seems to be a disconnect between the capabilities of LINQ (parameterised projection) and HQL here that will make this a bit difficult to fix...?