HashSet is not supported by SetParameterList

[AlPecin]

Hello,
I got a GenericADOException when enabling a filter in the session with SetParameterList("FilterA", HashSet<Guid>).

When I query the session with a hql statement I got the GenericADOException and the
inner exception said "System.Collections.Generic.HashSet``1[System.Guid]" cannot convert to type "System.String".

The reason seems to be that HashSet<T> doesn't implement the ICollection interface.

[fredericDelaporte]

May you please provide test cases? See Contributing for guidance.

The trouble you describe looks highly like NH-2955 which is fixed since NHibernate v4.

Your description seems to tell the trouble occurs both for filters and HQL queries, so then please provide a test for both cases.

[AlPecin]

I am not sure about NH-2955 because I'm using NH 5.0.3

SetParameterList("FilterA", Hashset) raise an exception
and
SetParameterList("FilterA", List) works correct.

[fredericDelaporte]

Adapting NH-2955 test cases for using a HashSet showcases no failure. It works. Please provide a full test case reproducing the issue. Unless it can be reproduced, it will be unlikely it will be fixed.

[hazzik]

The issue, most likely, in NHibernate.Engine.TypedValue. Issue is that HashSet<> does not implement System.Collections.ICollection (non generic). I have not tried to reproduce the issue - was looking into the code.

[fredericDelaporte]

The issue, most likely, in NHibernate.Engine.TypedValue.

This is instead likely another issue, like undue cache miss, affecting AbstractQueryImpl.SetParameterList too, while I suspect the AlPecin's case does not imply AbstractQueryImpl.SetParameterList which has been fixed by NH-2955, but only FilterImpl.SetParameterList.

Unfortunately his report is a bit confusing (it seems to imply the trouble occurs with non filter HQL queries too, which I do not reproduce) and partial (no actual test case, no complete detail of exception (especially stack traces).

In the filter case, there are two suspicious places: Loader.ExpandDynamicFilterParameters and NativeSQLQueryPlan.ExpandDynamicFilterParameters. Both seems to detect parameter lists by checking if they can be cast to the non-generic ICollection. It would be more robust if these implementations could use something more reliable, like a dedicated parameterLists for storing them separated from simple parameters, as do AbstractQueryImpl.

[hazzik]

FilterImpl.SetParameterList will end up in TypedValue