Just a quick update, if this helps - we are actually using the Dynamic
LINQ Library (we decided we need support for anonymous types)
http://msdn.microsoft.com/en-us/vcsharp/bb894665.aspx

and there is no ToList() there. Not a showstopper, I've already
implemented an Extension Method that does something similar, but just
decided to share since it might be interesting for you.

On Jul 23, 5:35 pm, Fabio Maulo <[email protected]> wrote:
> NH has and will have bugs as any others software.
> That is what everybody should assume.
>
> NH is not the best persistence framework in .NET ecosystem, it is "only" the
> most used, the most powerful, the most flexible so far.
> If a user can find something else that fit his needs, there is no problem.
> We can do our best but "make everybody happy" is not one of our target.
>
>
>
>
>
> On Fri, Jul 23, 2010 at 11:23 AM, Frans Bouma <[email protected]> wrote:
> > > and everyone should think that NH is not the place where ask the solution
> > of
> > > all evils.
>
> >         I don't think that's the point. The point is:
> > 1) if NH says it contains a working Linq provider, a user can only assume
> > it
> > indeed works. If it doesn't, the user can only conclude: the linq provider
> > doesn't work or has a bug. If a feature hasn't been implemented, the linq
> > provider is thus incomplete. Unfortunately, an incomplete linq provider is
> > more a burden than a blessing.
> > 2) if NH wants to be the best o/r mapper out there, a working linq provider
> > is essential. The main reason is that more and more people will learn about
> > o/r mapping and learn Linq, how it works etc. as there are many books,
> > articles written for EF and Linq to SQL and linq itself. If these people
> > can't use their knowledge with NH, the barrier to accept it as the best
> > there is is higher.
>
> >                FB
>
> > > On Fri, Jul 23, 2010 at 10:05 AM, Roy Jacobs <[email protected]>
> > wrote:
>
> > >       > > The 'ToList()' workaround is silly really, you don't want to
> > > fetch
> > >       > > all data to do an aggregate in-memory
>
> > >       > eh?!??!??
> > >       > NH ha to workaround RDBMS issue.
> > >       > NH have to work around to commercial companies visual components.
>
> > >       I think Frans' point is that even though the Count() seems
> > redundant
> > >       after a Take(), it's still a completely valid LINQ query.
>
> > >       Certainly, when one is directly writing the LINQ query, it's not a
> > >       problem to simply add a ToList(), but when working with third-party
> > >       components like the original poster is, it's not always reasonable
> > to
> > >       expect them to be able to modify the query.
>
> > >       Having said that, I think everyone is aware how complex writing a
> > > LINQ
> > >       provider is :)
>
> > >       --
> > >       Roy
>
> > > --
> > > Fabio Maulo
>
> --
> Fabio Maulo

Reply via email to