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
