|
From: Cameron H. (JIRA) <nh...@gm...> - 2011-05-10 09:57:51
|
[ http://216.121.112.228/browse/NH-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cameron Harris updated NH-2500:
-------------------------------
Attachment: NHBugRepro.zip
I've created an example for what I believe to be this bug (or at least related). It happens in every version of NHibernate I have tested, from NH3.0GA through to NH3.2Alpha3.
The bug occurs if you pass it a projection expression with the same structure twice, where the projection is a method on an object. The second time you call it, it will execute the method on the first object you passed in, which it appears to have cached. This incorrect behaviour appears to persist for the whole lifetime of the session factory, not just the current session or transaction. Hanging onto user objects could be a bit memory wasteful too..
var foos1 = s.Query<Foo>().Select(x => selector1.Map(x));
var foos2 = s.Query<Foo>().Select(x => selector2.Map(x)); // does the same as foos1
var foos3 = s.Query<Foo>().Select(selector2.Map); // works fine
= Expected output =
S1:Test 1; S1:Test 2
S2:Test 1; S2:Test 2
S2:Test 1; S2:Test 2
= Actual output =
S1:Test 1; S1:Test 2
S1:Test 1; S1:Test 2
S2:Test 1; S2:Test 2
> NH 3.0 Linq provider uses query parameters from first call in subsequent calls.
> -------------------------------------------------------------------------------
>
> Key: NH-2500
> URL: http://216.121.112.228/browse/NH-2500
> Project: NHibernate
> Issue Type: Bug
> Components: Linq Provider
> Affects Versions: 3.0.0.GA
> Reporter: Andrey Titov
> Assignee: Patrick Earl
> Priority: Critical
> Attachments: NH-2500.patch, NHBugRepro.zip, NHTest3.zip
>
>
> NH 3.0 Linq provider uses query parameters from first call in subsequent calls if this parameters are not propagated to SQL.
> //in first session
> this.number = 545;
> var cats = session.Query<Cat>().Select(cat => new CatInfo { Name = cat.Name, SomeNumber = this.number }).ToList();
> // all works perfect: all CatInfos contains 545
> //later in another session
> this.number = 842;
> var cats = session.Query<Cat>().Select(cat => new CatInfo { Name = cat.Name, SomeNumber = this.number }).ToList();
> // magic happens: all CatInfos contains 545 again
> I've debugged NH and found that in second query it gets QueryPlan from cache in NHibernate.Impl.AbstractSessionImpl.GetHQLQueryPlan() and it contains parameters from first call of query (NHibernate.Linq.NhLinqExpression.ParameterValuesByName) and then fails to replace them in NHibernate.Linq.NhQueryProvider.SetParameters() because they are not actual SQL parameters (query.NamedParameters).
> Sample solution is attached (VS2010, SQL Server Express DB). Put NH and LinFu.DynamicProxy binaries to .Libraries\NHibernate before build.
> I think actual parameters should be cleared from query (set to default(T)) before putting plan in QueryPlanCache to let them be garbage collected and prevent real magic happen in case of similar bugs.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|