Ah... Patrick... I forgot something... Where is published your Git clone of NHibernate's trunk ?
On Sat, Nov 20, 2010 at 8:05 PM, Fabio Maulo <[email protected]> wrote: > Thanks for your thoughts Patrick. > Nice invitation for the team members. > > On Sat, Nov 20, 2010 at 7:45 PM, Patrick Earl <[email protected]> wrote: > >> Thanks for your thoughts Fabio. You're obviously right that the Linq >> provider is only one of the query methods in NHibernate, though an important >> one in the .NET world. >> >> While I do believe the Linq provider can handle far more complexity than >> the old one, and is ready to go in other areas, I have a hard time accepting >> that it's really ready for production when the very first query I tried with >> the new Linq provider broke. It was the only Linq query in an app of >> significant size and it was handled fine by the old provider, but despite >> its simplicity, it failed on the new Linq provider. >> >> One area of significant deficiency is the handling of equality, >> specifically in the area of null comparison. For example, the following >> issues were present just looking at null equality: >> >> 1. The Linq provider is generating the wrong SQL for the = and != >> operators. For details, refer to NH-2402. It's clear that NHibernate's new >> Linq provider is the one with the issue here. >> 2. When I changed the null handling, zero tests broke, so this area >> wasn't even tested at all. >> 3. Query caching was broken with null variables. >> 4. The current code has other minor problems such as null == x and null >> != x not generating the same code as x == null and x != null. >> >> Another area of significant deficiency is in the area of working with >> parameters. People expect X == blah to work, but it doesn't work properly >> for even simple cases like string enums. People seem to use more than the >> most basic default ITypes for their columns frequently, and not being able >> to query those with Linq is a pretty major deficiency. Again, only the new >> Linq provider has issues here. >> >> So while I can't argue if the Linq provider might be ready for production >> in terms of the AST and advanced queries, it's pretty clear that there have >> been some basic areas that did not receive sufficient attention. >> >> As a side note, as I was poking around in JIRA I discovered yet another >> issue that would likely be fixed by the changes I've mentioned in this >> thread. These changes solve significant problems people are having and >> don't limit the future capabilities of the Linq provider. In fact the null >> equality change simplifies the code and improves the behavior at the same >> time. The other provides structure for context-aware AST operations in Linq >> and then utilizes that to solve the parameter problem in a way that could be >> easily modified in the future if need be. To give you some idea, applying >> the fixes discussed on this thread would close about 20% of the open Linq >> issues. In my view, that's pretty significant. >> >> To address some of your comments and questions: >> - By many issues, I guess I will just say that a fair number of open Linq >> issues deal with things that are tested and fixed by available patches. I >> accept that people are interested in different things, so this is pretty >> subjective. Feel free to ignore me here. :) >> - By attention or pertinent comment, I am looking for feedback from a team >> member that would help advance the issue towards resolution. These are some >> examples of what I would be happy to see: >> - An indication that the patch will be applied. >> - An indication of the existence of an alternate plan for dealing >> with this problem. >> - An indication that this problem has been considered and there are >> additional complexities. >> - Critiques of the patches that need to be addressed. >> - Discussion around ideas related to the issue. >> >> I welcome criticism of my code. I stand behind my patches and intend to >> quickly address any bugs or improvements that may come up. Your comment >> about "patches" implies that they are somehow band-aid solutions. While I >> can see how that could be argued for piece of issues like NH-2318, things >> like NH-2402 are complete solutions that address the issues in a well >> researched and rigorous manner. >> >> While I'm generally known for my patience, like anyone else, I don't have >> infinite time on my hands. I would be very happy if I could divert more of >> my effort into improving the state of things than into discussions that >> aren't even focused on generating solutions to problems. While it's clear >> that Steve put a massive amount of work into NHibernate's Linq provider, it >> seems like he's too busy to deal with things now. The commit graphs for >> NHibernate are actually a bit disheartening. It doesn't look like it's >> making the progress that it has in the past. Taking it one step at a time >> though, what can be done to ensure that the many bugs and improvements >> related to the Linq provider can be addressed in a timely manner? Is there >> a committer available that can help push things forward in that part of the >> project? Are there some other ideas to deal with the lack of availability >> of team members? Perhaps there could be a communal patch queue that would >> allow interested community members to analyze patches to help reduce the >> burden on core committers. >> >> So in summary, I would very much appreciate whatever can be done to make >> progress on the two most significant Linq issues discussed here. >> >> Patrick Earl >> >> On Sat, Nov 20, 2010 at 11:59 AM, Fabio Maulo <[email protected]>wrote: >> >>> I can understand your feeling. >>> >>> I would understand your definition of: >>> - pertinent comment >>> - no attention >>> - many issues >>> >>> The Linq provider is and will be our most popular source of issue/bugs >>> for the next two years, at least, but I'm sure that a lot of applications, >>> using NHibernate, are not using Linq to query the DB... perhaps "fundament", >>> "very important" are only the result of subjective point of view, >>> respectable but *a* point of view as any other. >>> The Linq provider, in NH, is only an option to query your persistent >>> domain; we have another 5. >>> >>> More than one year ago we take the decision to begin the release process >>> after Steve (Strong) has defined the new Linq provider as ready to be >>> released. We will release NH fixing what the team can do (using real >>> solutions and not patches) and then we can concentrate our effort for the >>> next release and, perhaps, some commiter can put the attention you are >>> looking for in the issues that are important for you. >>> >>> P.S. perhaps you will commit by yourself. >>> >>> On Sat, Nov 20, 2010 at 2:33 PM, Patrick Earl <[email protected]> wrote: >>> >>>> Hi all. >>>> >>>> While I'm thankful for all the work that was put into the Linq >>>> provider for this release, I'm rather disappointed in how the beta >>>> cycle has gone. We're facing release, and there are still many very >>>> important issues that haven't even been commented on in the Linq >>>> area. To give you some idea, in the entire beta period for the large >>>> chunk of code that the Linq provider is, only 4 issues have been >>>> resolved. During that same period, 25 new issues were created with >>>> virtually no activity on them. To give you some idea of what I'm >>>> talking about, here's a sampling of the issues. >>>> >>>> Numerous people have filed and voted about parameters not having the >>>> correct type: >>>> NH-2222 >>>> NH-2234 >>>> NH-2244 >>>> NH-2394 >>>> A patch is available in NH-2394, without a single pertinent comment. >>>> >>>> The null handling is another area with clear problems. You likely >>>> remember the long messages on the mailing list. There were also very >>>> few tests related to null handling, and numerous bugs. Despite the >>>> provider clearly handling nulls incorrectly, there has been no action >>>> on these issues. >>>> NH-2370 >>>> NH-2398 >>>> NH-2402 >>>> Again, there is a full patch with extended tests in NH-2402, but not >>>> even a single comment on this important issue. If NH goes to release >>>> without resolving NH-2402, it will cause breaking changes in the >>>> future. >>>> >>>> There are many Linq issues with patches and tests. I'll just name >>>> NH-2403 since I submitted it. Again, there has been no attention. >>>> >>>> Maybe I'm annoying, but I do find it quite frustrating when about the >>>> only thing that's progressing is the version number and the same bugs >>>> and limitations are still present. I've been happily using NHibernate >>>> for years, but it truly is disheartening when even serious / popular >>>> issues with full code and tests aren't addressed in any way. >>>> >>>> Patrick Earl >>> >>> >>> >>> >>> -- >>> Fabio Maulo >>> >>> >> > > > -- > Fabio Maulo > > -- Fabio Maulo
