Andy wrote:
On Apr 1, 10:17 am, "Frans Bouma [C# MVP]"
<perseus.usenetNOS...@xs4all.nlwrote:
try:
query = query.Where(c=>new List<string>(){"A",
"B"}.Contains(c.Type));
Linq to Sql isn't always smart enough to convert a constant
typed object into a value-based filter.
Hmm... well that works. Weird. I should have posted my actual
code... its like this:
List<stringtypes = new List<string>();
if ( conditionA ) {
types.Add( "A" );
}
if ( conditionB ) {
types.Add( "B" );
}
query = query.Where( c =types.Contains( c.Type ) );
So unfortunately I can't implement your recommendation.
I tried it with our linq provider (now in beta) and your initial query
works fine. It's also odd that it doesn't work in linq to sql: the new
List<string... is found by the 'funcletizer' routine in linq to sql's
engine which converts it into a compiled lambda and executes it. This
gives... a ConstantExpression with the actual object.
Your initial query has at the spot of the list parameter also a
ConstantExpression which represents the list object. Contains is a
difficult beast to implement (see my blog for details, I think it was
episode #12) though in this case, there's no real difference between
having a constant which is an IList and.... having a constant which is
an IList.
Perhaps you should post on the forums.microsoft.com linq forum, as
the linq to sql team is reading there and perhaps could help you
further. There are other cases where linq to sql gives up related to
Contains: it doesn't try to match source element's properties with
element to check (argument of Contains) in some occasions.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website:
http://www.llblgen.com
My .NET blog:
http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------