When you implements such kind of system you should be aware that each query hit DB and you should avoid unnecessary hit (as to know the amount of items of the actual page)
On Sat, Jul 31, 2010 at 11:12 AM, Rumen Stankov <[email protected]>wrote: > 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 > -- Fabio Maulo
