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
>
>
