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
