The new Linq parser will certainly throw if it sees expressions that
it can't translate. It also has some support for pulling various
parts of the expression out and executing "client side", although we
have to be *really* careful with this, since it could lead to very
unexpected consequences from a perf perspective.
Further down the road, I'm aiming to provide extension points so that
you can teach the provider about functions such as the one you have
below, but I'm not aiming for that in the first release.
Cheers,
Steve
On 10 Sep 2009, at 19:49, Ryan Bair wrote:
Hi all,
I'm exploring the NHLinq provider and came across a bug when trying to
call functions in the expression. Take this very simplified example:
class Person
{
public virtual int Id { get; set; }
public virtual bool IsOdd()
{
return Id % 2 == 1;
}
}
... and this query:
var foo = session.Linq<Person>
.Where(p => p.Id == 124) // 1 record up to this point, OK
.Where(p => p.IsOdd()); // Still 1 record!
So the end result is that I have one person with an Id of 124.
Obviously this should not be the case as 124 is certainly not odd. If
I convert to an enumerable or list first and then filter using the
method, all works as expected but we lose the NH magic.
We should at a minimum throw an exception if the provider isn't able
to run the query. Giving wrong results generally isn't desirable.
Should I file a bug/attempt a patch?
Going forward it would be interesting to pick apart the query into NH
and non-NH parts. In this case, the first expression would be in
NHable and the second would not. When we actually need to fetch
results, the NHLinq provider would do what it can and then stream the
results through the linq-to-objects provider to handle expressions in
the non-NH bin. In the case of subqueries, there could be some
bouncing back and forth between the two. I haven't thought it all
through yet, but I think it's doable.
The second idea might not make sense to attempt depending how the new
Linq provider is coming along. Any forecast on that?
