I have an idea for the new linq provider, which i am keeping it secret, but for current impl, a bug case in jira or a fix would be cool.
Tuna Toksöz Eternal sunshine of the open source mind. http://devlicio.us/blogs/tuna_toksoz http://tunatoksoz.com http://twitter.com/tehlike On Thu, Sep 10, 2009 at 1:49 PM, Ryan Bair <[email protected]> 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? >
