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
