Thanks a lot for your fast response. So I just used the wrong order of
Select and FetchMany. Changing the order in my case is not possible
because of using the poco from which I can't do an eager load ;-)

So I implemented your proposal of loading the entities with ToList()
and an afterwards "mapping" of properties to the poco.

Thanks,
Martin

On 23 Jul., 13:05, "Frans Bouma" <[email protected]> wrote:
> > after playing around a little with the new linq provider I got into
> trouble
> > when trying to use Fetch/FetchMany in conjunction with Select instead of
> > ToList. As I have understood I should use FetchMany when I want to eager
> > load an association - which is exactly what I want to.
>
> > The following statement works fine and I get all persistent objects
> (Config
> > objects with a 1 to many association 'Boundaries'):
> > var configurations = session.Query<Config>.FetchMany(x =>
> > x.Boundaries).ToList();
>
> > But when I use Select in order to load just a subset of the persisten data
> > of the Config object I'll get a NotSupportedException thrown in
> > PolymorphicQuerySourceDetector::GetClassName(IASTNode querySource):
> > var configPocos = session.Query<Config>.FetchMany(x =>
> > x.Boundaries).Select(x => new ConfigPoco { ID = x.ID, Boundaries =
> > x.Boundaries, ... };
>
> > Any idea? Am I doing something wrong?
>
>         Is 'Boundaries' a member of ConfigPoco?
>
>         The thing is likely that the eager loading is for entities, so if
> you were fetching Config instances, it is doable to eager load related data,
> however you are projecting the results into a custom class.
>
>         Eager loading directives IMHO should always be the most outside
> elements of the query, so after a select, as they tell the o/r mapper what
> to fetch _additionally_ to the query returned by select.
>
>         What your Select is doing is trying to do a custom projection AND an
> eager load of additional entities into 1 operation. I think you should
> either add a .ToList() in front of Select and do the custom projection in
> memory (which will thus use an extra materialization step for the Config
> entities) Or use a nested query in the projection for the boundaries instead
> of the FetchMany.
>
>         Btw, I don't know whether the NH linq provider modifies the
> expression tree to move any Fetch/FetchMany / eager loading directives to
> the outside of the query with a visitor.
>
>                 FB
>
>
>
> > Martin
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nhusers" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected].
> > For more options, visit this group at
> >http://groups.google.com/group/nhusers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

Reply via email to