Steve, I fully agree about the performance consequences. I'd even be careful with re-linq's option to execute ResultOperators (like count) in memory, this was a shortcut intended for providers that don't aim as high as Linq2NH. That said, there might be scenarios... As for extension points, the infrastructure is available in re-linq. We could look into that for you if you provide a shord description (or a link) about how NH is handling this on the HQL side. Couldn't find it instantly using google. (Is this already supported in the AST parser?)
On Sep 10, 9:47 pm, Steve Strong <[email protected]> wrote: > 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?- Hide quoted text - > > - Show quoted text -
