> 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
>
