Developing a LINQ provider without spending 2 minutes to think up test cases is a funny idea. Anyway, it's Patrick's call.
My old suggestion still stands: for development and testing purposes, draw a line between LINQ to HQL and HQL to SQL. A few end-to-end tests are find, but most of the testing should focus on either part. Otherwise, you're not just duplicating effort, but multiplying it. You can fully concentrate on getting complex queries to translate, and that's just how it should be from a LINQ provider perspective. (Same is true for trouble shooting: would be much easier if we could see the interim HQL, but I'm just repeating myself here) Stefan From: [email protected] [mailto:[email protected]] On Behalf Of Fabio Maulo Sent: Tuesday, December 14, 2010 6:07 PM To: [email protected] Subject: Re: [nhibernate-development] Re: NH3.0.0 perhaps... but in this way the user have to hope that somebody else have to find the bug for him. At each Alpha version of NH I'm personally inviting people to download NH and try it because we done our best (as Steve Strong done) to cover more cases as possible at least all we found in the commercial project we are involved and we know that we are not covering all possible usages. We can continue talking but I don't think that, even with 36 hours per day, Patrick will dedicate 2 minutes imagining a possible combination of entities/mapping/Linq; he can be a good developer but to be a fortune-teller he needs something else. any way... +7600 downloads in the first 10 days of the release is a very good result. Again CONGRATULATION Team!! And CONGRATULATION even to Jason Dentler for the new best-seller for Packt-pub; this was the first time where a book covering a specific version of NHibernate was published in sync with the release. On Tue, Dec 14, 2010 at 1:34 PM, Wenig, Stefan <[email protected]<mailto:[email protected]>> wrote: That's one way to approach it. Given a dedicated user base, this will over time lead to a working provider. Normally, people will just not feel like testing something if the development team didn't bother to find at least the bugs that are easily discoverable. But for OSS, this might work, if slowly. It will piss some people off though. The low number of LINQ-related issues could be an indicator that people think it's a piece of crap and don't even bother to file issues any more. The other way would be to get the thing into a state that meets a certain quality standard, and gives users reason to think that it will soon be usable for them. And only then ask them to find the remaining bugs. The funny thing is that this is often less effort too, because you don't need all the issue-tracking bureaucracy. I hope that Patrick finds some time to just work on it. (Then there would probably have to be some minor release with a clear statement to restore enough hope in people to give the LINQ provider a second chance.) Just my two cents. HTH, Stefan -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Fabio Maulo Sent: Dienstag, 14. Dezember 2010 15:55 To: [email protected]<mailto:[email protected]> Subject: Re: [nhibernate-development] Re: NH3.0.0 where are yours issues, related to the problems you are talking about, in our JIRA? You are talking about "users"... and what about you ? If you are really worried about NH quality, create new JIRA tickets, with a test, is the first step to help the project. About people using EF4 I can't see where is the problem, with them there are some others billions of people not using NHibernate. For me, no issues reported by neither by users nor by committer, and increasing number of downloads, mean: everything is working as we need. -- Fabio Maulo El 14/12/2010, a las 11:31, Kakone <[email protected]<mailto:[email protected]>> escribió: > "it seems to be enough stable"... It's a joke or we don't use the same > version ? > Yes, if you do a simple Select, it's stable. But, each time I want to > do something a little more complicated (some simples OrderBy, Left > Join, ...), it doesn't work well. > Congratulations for the accomplished work but you can't say that it's > enough stable (or we do not have the same conception of quality). > Actually, to my mind, the LINQ provider can't be used in a real > business application. Since Steve Strong stopped the developement, > nothing - or almost - has changed. I'm not complaining because it's an > open source project and all the people do their best to improve it (if > I had time, me too), but you can't say that "it seems to be enough > stable". All the users of the new LINQ provider think that this new > LINQ provider is in beta state (also Patrick : > http://blog.patearl.net/2010/12/nhibernate-30-linq.html). > > But, you are right, if very few new issues were added to Jira, I think > also that the reason is something else : > 1 - most of the users will not add an issue to Jira, > 2 - most of the users that want a LINQ provider that works well, uses > Entity Framework. > And I still think you are mistaken when you think the LINQ provider is > not so important for NHibernate users. > > On 14 déc, 13:48, Fabio Maulo > <[email protected]<mailto:[email protected]>> wrote: >> at the moment 7660 downloads in 10 days. >> very few new issues regarding the LINQ provider. >> Perhaps I was wrong thinking that the LINQ provider will be the mayor source >> of issue for the next two year... it seems to be enough stable...hmmm or >> perhaps the reason is something else. >> Btw, CONGRATULATION for your work! >> >> On Tue, Dec 7, 2010 at 12:10 AM, Fabio Maulo >> <[email protected]<mailto:[email protected]>> wrote: >>> Hi team. >>> Only to be actualized about one of the result of our work: >> >>> http://sourceforge.net/projects/nhibernate/files/NHibernate/3.0.0.GA/.<http://sourceforge.net/projects/nhibernate/files/NHibernate/3.0.0.GA/>.. >> >>> -- >>> Fabio Maulo >> >> -- >> Fabio Maulo -- Fabio Maulo
