[nhibernate-issues] [NHJIRA] Commented: (NH-2500) NH 3.0 Linq provider uses query parameters from first call in subsequent calls.

[Nicola T. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20506#action_20506 ] 

Nicola Tuveri commented on NH-2500:
-----------------------------------

Hi Patrick.

1. Good point. I'll write some tests to cover more complex queries, starting with subqueries. 
Using a property to set the list of constants like I did it's dirty, I know. 
On the other hand the constructor of ResultTransformer is called before the query is cached, so constants would be cached as well.
I'll try to find a better way to accomplish this, checking other classes as well. 
Could ExpressionQueryImpl and HQLExpressionQueryPlan along with thier related interfaces be good candidates?

I'll check how NHibernate handles constants in regular (non Linq) queries too.

2. Yes I did, but I don't understand the exact point you are referring to. 
I would be happy to adjust ExpressionKeyVisitor following your suggestion.
 
3. Right. Are you referring to the Constants property of the result transformer?

Thanks for reviewing the patch!

> 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, 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