Hi a lot of time has already been invested in the new LINQ provider. Our own re-linq library has received a complete overhaul to make it a good foundation for LINQ 2 NH, and Steve Strong is currently busy building the new provider on top of it.
Everyone understands the limitations of the current provider. It provides some basic functionality, and for those scenario it supports, it's stable. But I assume everyone would agree that it's essentially a prototype that became a stop-gap solution because of popular demand. If you want best of breed performance or functionality today, use something else (Criteria, HQL ...). AFAIK the current provider is not actively maintained, so there's no point complaining. There's also no point defending the status quo. A lot of active and potential users of NH will consider this a decision factor. And while I understand that the market share of NH is not a primary issue for everyone, I think we all agree that a certain competitiveness wouldn't hurt, not? So here's what you can do if you want to see progress with the new provider: - Offer to help out with development. Contact Steve or post to the developer list. Steve is mostly asking for tests, but given enough volunteers, he might consider opening up his dev process a bit. - Encourage an active discussion on the developer list about where LINQ2NH should go, what the priorities are, how certain scenarios should be handled etc. I really dont't think that this should be such a controversial topic. Some people care more about LINQ than others, so what. This is OSS, those who care will get it done. In the end, NH will have a great LINQ provider, both capable and fast. BTW, I don't think that it will be particularly fast out of the box, since it uses a rather elaborate architecture. re-linq and HQL raise the level of abstraction, these things usually take some time. It should not be particularly slow either, but don't expect performance as in LLBLGen's provider. What we're probably going to do is transparent caching, so the processing time of LINQ to NH only hits you once. (Don't confuse that with LINQ to SQL's explicit compiled queries, they're a PITA.) Cheers, Stefan www.re-motion.org On Oct 22, 2:15 am, John Rayner <[email protected]> wrote: > Check > outhttp://ayende.com/Blog/archive/2009/04/30/nhibernate-ndash-the-differ... > for some tips on how to speed up this particular query, > > On Oct 21, 11:13 pm, aemami <[email protected]> wrote: > > > > > Here is an example of a query that performs poorly compared to a > > competing vendor's product: > > > public IEnumerable<User> SearchByUserId(int userId) > > { > > return session.Linq<User>().Where(user => user.Id == > > userId); > > } > > > This is a very straightforward query. > > > And in response to Fabio - why would I want to write this in an OOP > > manner, when the functional approach is clear, concise, easy to read, > > and substantially easier to modify/maintain? > > > On Oct 20, 6:27 am, Fabio Maulo <[email protected]> wrote: > > > > 2009/10/19 aemami <[email protected]> > > > > > You guys really should focus on LINQ. Most people don't want to use > > > > the Criteria api or HQL. That is NHibernate-specific technology, > > > > which is silly to learn when you could be learning a mutli-use .NET > > > > technology such as LINQ. > > > > WELCOME in ObjectOriented world!!! > > > > We are focused in Object Oriented queries since .NET1.1. Have you learned > > > about it only since .NET3.5 ? > > > > -- > > > Fabio Maulo- Hide quoted text - > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
