The Dynamic-LINQ is that using strings instead of strongly-typed ? On Sat, Jul 31, 2010 at 11:18 AM, Rumen Stankov <[email protected]>wrote:
> Just a quick update, if this helps - we are actually using the Dynamic > LINQ Library (we decided we need support for anonymous types) > http://msdn.microsoft.com/en-us/vcsharp/bb894665.aspx > > and there is no ToList() there. Not a showstopper, I've already > implemented an Extension Method that does something similar, but just > decided to share since it might be interesting for you. > > 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
