I think it's a matter of looking at LINQ as an API or as a standardized protocol. An API can live with a few unsupported corner cases, just avoid them. For a protocol it's different, because you don't control the source of the query. I think that Frans makes a good point here, but of course: whether the NH team ultimately wants to support this kind of LINQ usage is up to you.
But I don't think there's a reason to argue against fixing it unless Steve doesn't want to do it. And even then, you can still ask for a patch. Might gain a new contributor along the way. The good thing about OSS is that everybody _can_ be happy, even if their priorities are different from you. They just need to contribute. (I'm simplifying, but I don't see a conflict of interests here, just priorities.) Cheers, Stefan From: [email protected] [mailto:[email protected]] On Behalf Of Fabio Maulo Sent: Friday, July 23, 2010 4:36 PM To: [email protected] Subject: Re: [nhibernate-development] Re: Linq-to-NHibernate issue with paging and counts 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]<mailto:[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]<mailto:[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
