Just a reminder: this issue (skip/take/count) has only been reported for the old contrib-provider, not for NH3.
Gesendet von meinem HTC ----- Ursprüngliche Nachricht ----- Von: Rumen Stankov <[email protected]> Gesendet: Samstag, 31. Juli 2010 16:19 An: nhibernate-development <[email protected]> Betreff: [nhibernate-development] Re: Linq-to-NHibernate issue with paging and counts Hello Folks, I'm working on the grid in question, Trirand's jqGrid for ASP.NET WebForms/MVC: http://www.trirand.net/demoaspnetmvc.aspx Thanks to Alastair for starting this obviously very popular thread. The reason the query is written that way Skip(x).Take(y) is that "y" is the fixed page size of the grid, say, 10, but we can be on the last page and the actual page size would be, say, 6 - hence we need the count and it might be different than "y". That said, we are definitely interested in making sure we work with NHibernate (and in fact any other popular ORM engines out there like LLBLGen), so we will probably use some of your ideas and modify the LINQ query sequence so that count is correct. Thanks a lot for the suggestions. Regards, Rumen Stankov Trirand Inc. 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
