I hadn't published it previously. It's up on github now. I only pushed my feature branches since my master has a bunch of VS2010 changes on it. I haven't merged from the trunk in a few weeks.
https://github.com/patearl/NHibernate/network Patrick Earl <https://github.com/patearl/NHibernate/network> On Sat, Nov 20, 2010 at 4:09 PM, Fabio Maulo <[email protected]> wrote: > 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 > >
