The only way to do that in HQL is registering the IsOdd function. At that pointfrom Person p where IsOdd(p) = true
HQL is persistence oriented. In the new parser we can recognize some extension-method and translate the sentence in an efficient persistence-sentence. For custom methods we can provide (in the future) some way to register its persistence-side-translation. If a specific LINQ sentence will have a lot of in-memory-complex-method well... IMO the user should divide the persistence-side from in-memory-side in some way. 2009/9/11 Stefan Wenig <[email protected]> > > 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 - -- Fabio Maulo
