NHibernate 3 and Linq Provider

[Patrick Earl]

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]

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.

--
Fabio Maulo

[Patrick Earl]

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

[Fabio Maulo]

Thanks for your thoughts Patrick.

Nice invitation for the team members.

--
Fabio Maulo

[Fabio Maulo]

Ah... Patrick...

I forgot something...

Where is published your Git clone of NHibernate's trunk ?

--
Fabio Maulo

[Patrick Earl]

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

[Julian Maughan]

I should have time to review your Linq patches this week...

[James Kovacs]

I can understand your point of view, Fabio, that NHibernate has 5
other query mechanisms - many more mature - than the LINQ provider.
The reality in the .NET space is that LINQ is king. The preferred
query mechanism for LINQ-to-SQL and EF are both LINQ. Look at the
uptake of LINQ-to-NHibernate even though it's a proof-of-concept.
Having a solid LINQ implementation in v3 - as Patrick is pushing for -
will have a dramatic effect on the acceptance of NHibernate outside
its core demographic of current NH users or those coming from
Hibernate. For example, I tried a simple LINQ query with an orderby
clause and it failed with a Antlr.Runtime.NoViableAltException.

var query = from foo in session.Query<Foo>()
orderby foo.Bars.Count()
select foo;

(As you can probably guess, a Foo has a collection of Bars.) Writing
this same query in HQL works just fine:

var query = session.CreateQuery("select foo from Foo foo order by
size(foo.Bars)");

Yes, HQL is much more mature. I realize that. Newcomers to NH will
not. They'll get that wacky exception and won't think, "Is there
another way I can query with NH?" They'll think, "NH is broken."

This isn't meant to detract from the work that Steve Strong has done.
He has done an amazing job in building up the foundation, but as
Patrick points out, LINQ needs some polishing. We've got patches with
test cases waiting for evaluation. Can we try to fix the major (and
hard-to-fix later) issues before NH3 releases? Please? Pretty please?

James

On Nov 20, 11:59 am, Fabio Maulo <fabioma...@gmail.com> 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.

[Fabio Maulo]

Do you mean before 2010/12/04 ?

--
Fabio Maulo

[Patrick Earl]

Here's a breakdown of the JIRA issues for the LINQ provider:

Things that will cause breaking changes (probably missed some, but these were obvious):
2099 (arguable if it should be done)
2402
2412

Bugs:
7 with fixes
12 with tests and no fixes
14 with no tests and no fixes

Improvements:
4 with fixes
1 with tests and no fixes
4 with no tests and no fixes

I'd say that it would definitely be a good idea to address 2402 and 2412 ASAP.

For bugs with tests and fixes already available, there are:
2203
2375
2381
2394 (fixes several open issues)

In general, it looks like NHibernate 3.0 will have a Linq provider in more of a beta state.  That should be okay though since the release will get the rest of the many important changes out there and free people's hands to dig a little bit deeper in the Linq provider.  Releasing will also likely generate more bug reports and patches as people start to use the new Linq provider.  That said, there is the down side that people might be more disappointed with the provider.  Perhaps it could be made clear in the release notes that the provider has come a long way, but we can still use people's feedback to get it polished up.  Would at least get people's expectations more in line with how things seem to be going.

Is adding a note like this a good idea, or have people's general experiences with the Linq provider been good enough that it doesn't seem to matter?  Looking through the issues there are still a number of regressions from the original NHibernate.Linq.

Just some thoughts... do what you will with them. :)

        Patrick Earl

[Fabio Maulo]

Patrick, what Julian said to you is not enough ?

Are you looking for a specific commiter ?

Do you want become part of the team ?

--

Fabio Maulo 

[EA]

From the point of view of a new comer to NHibernate I could not agree
more with James and Patrick, the Linq provider is the way to go, it
should be given a high priority. I have been using the Linq provider
in a couple medium size projects this year and it really pays off
using it. It streamlined my back-end repository design and makes other
developers to love it, we still use HQL or Criteria and other
providers for more specialized tasks but the most common queries are
executed using Linq.

Enrique

> > Fabio Maulo- Hide quoted text -
>
> - Show quoted text -

[Wenig, Stefan]

Fabio,

 

ask anybody who is only remotely familiar with NH, what’s going to be the big difference in 3.0, and all they’ll be able to think of (if anything) is LINQ support. That’s not to say the other improvements are not important, but people won’t relate to them unless they become really familiar with NH.

I think the question of how to communicate the deficiencies of the current provider is not only legitimate, but also very important. It all again boils down to the question: is anybody here really interested in positioning NH to a greater community? If you do, you don’t want to see people bitching about how broken NH3 is right after release.

 

Personally, I’d even consider delaying 3.0 release if there is a new team member (assuming that Patrick accepts the invitation) willing to put some effort into the provider right now. It would be a shame to release something that looks half-assed from the outside, when really Steve already all did the hard work, and all that’s left to do is a little polishing on the surface (yes, there are a few biggies left, but that’s not as bad as the little things that break unexpectedly all the time).

 

If you don’t want to wait, I suggest you announce a 3.1 release right away and keep expectations for the LINQ provider low for now. But that’s just me.

 

Cheers,

Stefan

[Wenig, Stefan]

Thanks for the breakdown!

 

I’d suggest closing 2099, it’s not really an issue, but a mere observation with a discussion that went nowhere. The current behavior is just fine.

 

The tests for 2381 look incomplete to me. I left a comment.

 

Cheers,

Stefan

 

From: nhibernate-...@googlegroups.com [mailto:nhibernate-...@googlegroups.com] On Behalf Of Patrick Earl
Sent: Tuesday, November 23, 2010 3:17 AM
To: nhibernate-...@googlegroups.com
Subject: Re: [nhibernate-development] Re: NHibernate 3 and Linq Provider

 

Here's a breakdown of the JIRA issues for the LINQ provider:

[Diego Mijelshon]

I agree with Stefan and Patrick.

The reasonable expectation of most users is that NH 3 Linq will not only support a lot more constructs than Contrib Linq, but also that it will be a superset of that, and that queries that used to work will keep working just by changing .Linq to .Query.

We can say "Contrib is not official" all we want, but pretty much everyone that started using NH in the past 2 years is using Linq and would like NH 3 to work with their existing codebase.

I also agree on planning and announcing a 3.1 release focused on Linq functionality. That will give us some time to polish things.

I've uploaded a patch for http://216.121.112.228/browse/NH-2416 this weekend. It made me realize some areas were completely overlooked (I'm also gonna upload a patch to support ContainsKey).

Again, this should not be seen as a lack of regard for the excellent work done by Steve, Fabio and others, but as an acknowledgement that Linq is huge and we're still not done there.
 
    Diego

[Fabio Maulo]

From my point of view Linq is just another way to query the DB using NH.

Linq is not more strongly typed than QueryOver and is not more easy to learn than HQL.

"Strategically" Linq is important... a strategy for what ? a commercial plan ?  a war ? a competition ?

We are at one year of NH2.1.2 who has +104000 downloads, the Linq provider for NH2.1.2 has 25000 downloads; 25% of NH's are really interested in Linq ?

Yes, the actual implementation of Linq is limited; one of the session of the nh-day Europe was dedicated to these limitations.

We can show our limitations even in a day fully dedicated to NHibernate.

For years I saw demos where the capability to translate a Linq sentence was the center of the "show"... until a DBA have seen the ugly and inefficient queries generated. 

Do you really want wait until we have a full-supported-Linq, before release NH3.0.0 ?

I prefer to give some others options about the configuration, another very powerful and strongly-typed query system (QueryOver), new dialects, new natively supported types, various bug fixes and some improvements to the 75% of users working in "the dark side of the force".

--
Fabio Maulo

[David Pfeffer]

Personally, if NH3 is released without the issues with the LINQ provider working, I'm going to have to keep my project using the trunk so that I can get at the LINQ bug fixes. Right now I have HQL scattered throughout my project, and I really want to replace all of the queries with LINQ so that I can reduce coupling to NHibernate. I'm sure many other people would follow suit.

I'm not saying its necessarily a negative that I and others might not be able to use the release version of NH, but you have to decide if its important to you that people be able to use your release product. Right now from talking to my friends in the developer community, nearly all of them think NH has a reputation that "you always have to use the trunk."

[Wenig, Stefan]

Fabio,

 

this is really frustrating. Now that the LINQ provider is almost ready for showtime, all we’re hearing from you is basically that you don’t care because there’s 50 other ways to query NH, world of choice, etc.

 

As far as LINQ support goes, this is not a 1.0 release, this is a beta. A 1.0 release could live with a limited scope, such as no outer joins or grouping, but not with completely arbitrary failure to execute many non-trivial queries. And I don’t believe there’s a lot missing to get to a stable, well-defined 1.0 release. A few bugs will always be there, but that’s not the same thing.

 

I’m not saying you need to stop NH3 in its tracks until LINQ is fully supported. I only said that *I* would *consider* delaying it a bit if there’s a chance to get *some* stuff done right now. Patrick seems to be on it, so why don’t you show him some love?

 

If you’re not delaying, there should be an early public announcement of a 3.1 release, and LINQ support should officially be declared beta for LINQ in 3.0. I’m repeating this because you chose to ignore it.

 

Now you don’t like LINQ, and you don’t care what people think about NH. Message received. But I predict you will be the first to wipe the floor with anyone who dares to call NH3 a piece of crap because of LINQ problems. Why not address the problem before that happens?

 

Stefan

 

 

From: nhibernate-...@googlegroups.com [mailto:nhibernate-...@googlegroups.com] On Behalf Of Fabio Maulo
Sent: Tuesday, November 23, 2010 1:35 PM
To: nhibernate-...@googlegroups.com
Subject: Re: [nhibernate-development] Re: NHibernate 3 and Linq Provider

 

From my point of view Linq is just another way to query the DB using NH.

[Richard Brown (gmail)]

Just to clarify ...

 

>  this is really frustrating. Now that the LINQ provider is almost ready for showtime, all we’re hearing from you is basically that you don’t care because there’s 50 other

 

It is not the correct message to think that we don’t care about LINQ.

 

>  Patrick seems to be on it, so why don’t you show him some love?

... and we are awaiting Patrick’s response to the invite to become a committer.

[Patrick Earl]

On Tue, Nov 23, 2010 at 8:33 AM, Richard Brown (gmail) <fluk...@googlemail.com> wrote:

>  Patrick seems to be on it, so why don’t you show him some love?

... and we are awaiting Patrick’s response to the invite to become a committer.

I'd be happy to help as much as my time allows. :)  I have some informal understanding of what's involved in being a committer, but are there any official guidelines anywhere?

        Patrick Earl

[Fabio Maulo]

On Tue, Nov 23, 2010 at 11:00 AM, David Pfeffer <byt...@bytenik.com> wrote:

Personally, if NH3 is released without the issues with the LINQ provider working, I'm going to have to keep my project using the trunk so that I can get at the LINQ bug fixes. Right now I have HQL scattered throughout my project, and I really want to replace all of the queries with LINQ so that I can reduce coupling to NHibernate. I'm sure many other people would follow suit.

LOL. The repository pattern is for something.

string SQL spanned everywhere, HQL spanned everywhere or LINQ-to-DB spanned everywhere make no difference.

before IL compilation a LINQ sentence is a string as before NH compilation (BuildSessionFactory) a HQL is a simple string. 

 

I'm not saying its necessarily a negative that I and others might not be able to use the release version of NH, but you have to decide if its important to you that people be able to use your release product. Right now from talking to my friends in the developer community, nearly all of them think NH has a reputation that "you always have to use the trunk."

what ?

The trunk is only for one thousand of pioneers.

--
Fabio Maulo

[Fabio Maulo]

An example of commitment can be:
"I would mostly help with the LINQ provider giving more attention and pertinent comments to the many issues we have and we will have over LINQ."

If it work for you then you are welcome.

The mayor rule is: nobody can commit something breaking an existing tests.

If you have some doubt about some proposal coming from users the dev-list is the place where talk. 

That is all.

If you agree you are in.

--
Fabio Maulo

[James Kovacs]

For the breaking changes, I think they need to get in before release
assuming that there are no major issues with the patches. For the
rest, I like Patrick's idea of making it clear that the LINQ provider
is more beta than RTM and not the recommended query mechanism for this
release. Let people try it and we'll polish it in the coming weeks/
months.

Not sure how much help I can be in resolving some of these issues as
I've never dug into the new LINQ provider, but I'm willing to roll up
my sleeves and take a look at some of the issues. I have debugged (and
patched) other areas of NHibernate. So I'm not coming in completely
green. :)

James

On Nov 22, 3:13 pm, Fabio Maulo <fabioma...@gmail.com> wrote:
> Do you mean before 2010/12/04 ?
>

[Fabio Maulo]

I don't know which message you have received, I didn't send you any message. 

I like LINQ (to object) and I care about what people say about NH; perhaps I listen some different people than you.

--
Fabio Maulo

[Fabio Maulo]

James,

have you heard me saying that the LINQ-provider is the most important feature of NH3 and it represent the better way to query the DB in NH3 ?

Did you read a post announcing the final release of NH3 ?

Can you, and some others NH's MVP, write some posts with yours opinions about the coming soon release ?

You and other have the door of nhforge.org opened to write what you want about NHibernate and its ecosystem; you don't have to ask permission just because you have it already (since the beginning of nhforge.org)

Why you have to ask me to write an early post about NH3 when you can help doing it by yourself ?

--
Fabio Maulo

[Fabio Maulo]

A note about people scared by NH codebase.

Don't worry!! I know many areas of NH codebase but nobody can say "I know all NHibernate".

NHibernate changes day by day and it has (only in nhibernate\src\NHibernate) 3500 files in 829 folders.

Nobody of NHibernate committers have received a "guide line document" or a different documentation than what is already public.

As personal taste I prefer those people working hardly in the silence instead those making pompous announcement in dev-list or announcing each fix with a mail to dev-list. The last issue id is 2424 but we have just 293 issues opened... when you have fixed 20 issues you can calculate your % over the work done by others. Before start the NH3.0 release process the amount of opened issues was around 340 and in the process we have analyzed, commented and fixed or closed around 100... for some sort of lucky you didn't see 100 mails in dev-list... what you saw is people working in the silence and BRUTUS (myself) answering in dev-list to those users asking for more and more. In the last 2.5 years the NH team was increased by 8 members (avg of one member each 8 months); each one took a commitment at the begin, then each one have done what he can.... so, don't worry!! do what you can do for the project you like to use today, you will always find somebody saying that you didn't done enough... tomorrow will be another day.

--
Fabio Maulo

[Patrick Earl]

My commitment is to contribute what time and ideas I have to improving NHibernate.  I want to help, not just in code, but in areas such as documentation, testing, and packaging.  For the time being, I intend to focus my energy on solidifying the Linq provider, fixing issues and providing even more tests.  While I'm certainly no expert, I look forward to helping out however possible.  I definitely appreciate the time people put in to review and discuss changes, and I'm sure I'll continue to have plenty of questions and requests for review.

I don't want to sound like I'm running for political office or something, but I do appreciate people's recent support.  Excited about continuing to help inch NHibernate forward. :)

        Patrick Earl

[Stefan Wenig]

On 23 Nov., 17:09, Fabio Maulo <fabioma...@gmail.com> wrote:
> I like LINQ (to object)

That about sums up the problems I have communicating with you, and the
frustration I'm experiencing.

[Stefan Wenig]

Patrick,

congratulations, glad you're in! I'm not a member of NH, but I'm in
charge of re-linq, which NH's LINQ provider builds upon. re-linq
basically just works, but there have been a few issues in the past
that we could solve for you (like VB support), that we will solve soon
(like using IQueryable objects in queries,
http://groups.google.com/group/nhusers/browse_thread/thread/441d3289fea5ad0d)
and some where we found we should not implement them in re-linq, but
rather help you building it (like conversion of DefaultIfEmpty to
outer joins).

We're no experts in NH or HQL, but we like to help out if we can. Just
make sure you give us some context when it gets too NH-specific. One
problem I keep having is that on this list, the discussion often
evolves around LINQ to SQL conversion, when really the process is a)
LINQ to HQL and b) HQL to SQL. Since I'm only concerned with (and only
understand) a), that would be one thing to keep in mind when
discussing LINQ stuff with us.

I also think that for troubleshooting, it would help a lot if NH's
LINQ provider could write the HQL AST it generates as a string. I
believe this would in many cases make the source of an error much
easier to locate. Steve once mentioned that he could do that, but I
think he didn't have much time at his hands to spend on LINQ2NH
lately.

I'm watching this list, so I believe is Fabian, who owns the code of
re-linq. You're also welcome at http://groups.google.com/group/re-motion-users/

Cheers,
Stefan

relinq.codeplex.com

> > Fabio Maulo- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

[Fabio Maulo]

don't worry, the frustration is mutual.

--
Fabio Maulo

[Wenig, Stefan]

That does a world of good to me. I’d rather have both of us not be frustrated, but as much as I try, I can’t find a way to get a reasonable conversation going.

 

From: nhibernate-...@googlegroups.com [mailto:nhibernate-...@googlegroups.com] On Behalf Of Fabio Maulo
Sent: Wednesday, November 24, 2010 1:32 PM
To: nhibernate-...@googlegroups.com
Subject: Re: [nhibernate-development] Re: NHibernate 3 and Linq Provider

 

don't worry, the frustration is mutual.

[Fabio Maulo]

I said: "don't worry"

--
Fabio Maulo

[Dmitry]

I want to say thanks to Patrick for trying improve the LINQ provider.
In my opinion, and it seems like I am not alone, LINQ is the biggest
usable addition to the NH3.

Everyone should realize that even though LINQ is by far not the only
way to create queries in NHibernate, it makes NHibnerate much easier
to adopt by organizations. Nobody wants to learn multiple proprietary
query syntax at least during the initial learning curve.

[pvginkel]

Totally agree. Thanks Patrick.

[Kakone]

On 26 nov, 03:17, Dmitry <dmitry.staro...@gmail.com> wrote:
> I want to say thanks to Patrick for trying improve the LINQ provider.
> In my opinion, and it seems like I am not alone, LINQ is the biggest
> usable addition to the NH3.

You are not alone :-)
As I'm trying to use NHibernate with WCF RIA Services, LINQ is very
important (I can't use another query method, otherwise, I lost all the
benefits of RIA Services). For the moment, i don't know if I will
continue to use NHibernate due to the issues with LINQ provider. So,
i'm happy to see that someone try to improve the LINQ provider (I
tried to enter the source code but it's not very easy...).

[Fabio Maulo]

Weborb is a real-world demostration on how use NH, especially HQL, in
a RIA... even direcly from jscript or whatvever you want.
But... well... In .NET world LINQ is the real COOL thing.

--
Fabio Maulo

[Steve Strong]

Awesome!  As you all now / have guessed, I've been completely snowed under with work-related work for the last couple of months, and have had 100% intention but 0% time to do anything with the Linq provider.  And it's really pained me to have done so much work, to know that it's so close to being useable, but to also know that there were various glitches that would have been show-stoppers had they not been fixed.

So catching up on the list today, I'm absolutely delighted to see Patrick on board and the great work that he's already done - fantastic work, and THANK YOU!!

If there's anything in the code (either what the code is doing or what the hell was going on in my head when I wrote it), feel free to email / skype me directly and I'll do my best to help you out.

Cheers,

Steve 

-- 
Steve Strong
Sent with Sparrow

On Monday, November 29, 2010 at 4:02 PM, Fabio Maulo wrote:

Weborb is a real-world demostration on how use NH, especially HQL, in
a RIA... even direcly from jscript or whatvever you want.
But... well... In .NET world LINQ is the real COOL thing.

--
Fabio Maulo


El 29/11/2010, a las 11:32, Kakone <stepht...@gmail.com> escribió: