Couldn't we just rely on formula properties? So expressions against formula properties would get evaluated at the server and expressions against compiled IL methods or other non-mapped properties would get executed on the client.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Darren Kopp Sent: 14 September 2009 19:31 To: nhibernate-development Subject: [nhibernate-development] Re: Problem with method calls in LINQ provider Damien Guard has blogged about this, and this is the idea that he has put forth: http://damieng.com/blog/2009/06/24/client-side-properties-and-any-remote-linq-provider. nothing official yet. this idea would solve this scenario currently if you did Expression<Func<Person,bool>> isOdd = p => p.Id % 2; usage would be var foo = session.Linq<Person> .Where(p => p.Id == 124) // 1 record up to this point, OK .Where(isOdd); and the instance method would be public bool IsOdd() { // probably would want to cache this compilation because only needs to be done once. // after compiled, invoke against this instance return isOdd.Compile()(this); } On Sep 11, 6:07 am, Fabio Maulo <[email protected]> wrote: > 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
