Jon said:
Well, NHibernate 2.0 went beta 1 at the end of June:
http://blog.domaindotnet.com/2008/06/29/nhibernate-20-goes-beta-1-
while-microsoft-linq-to-entities-receives-vote-of-no-confidence-from-
many-leading-net-experts-as-unacceptable/
2.0 doesn't contain a full linq provider. It's in the contrib lib.
As Pavel asked, do you have any evidence to suggest that people
shouldn't expect it to be released with LINQ support in a reasonable
timeframe?
See my reply to him.
You don't have to take my word for it, but don't be surprised that it
won't work properly either. I mean, it doesn't have support for
GroupJoin for example, which is something a tad more complex than from
where select stuff. Does it do group by's on join stacks? Group by's on
related entity data? etc. there are so many scenario's thinkable where
the expression tree looks a slightly bit different and you have to pull
essential information from another subtree than you'd expect (e.g. which
element in the join stack to target for the group by fields, thus
which alias to use? that's not really determinable from the groupby
method call in cases where the join is between the same entity so you
have to dig deeper)
The thing is that writing a linq provider which can handle *all*
queries you throw at it isn't a small thing. It took me 8 months of full
time development and often the material is very very complex simply
because there's little to no documentation and you practically work in
the dark. Add to that that the VB.NET compiler often creates trees which
look a tiny bit different, and you're in for a heck of a time
.
As this linq provider moves forward very slowly, they've a lot of work
ahead of them. The downside of writing a linq provider is that you need
to work on it without interceptions, as processing the tree to create a
smaller, better to understand tree which then is reprocessed etc. is
something you can't do on an afternoon, you've to think things out,
design parts, implement them, test them, think through if you've covered
all the scenario's, because handling a given TYPE of subtree in a
general way means that it's handled EVERYWHERE by that routine due to
the visitor nature of the handlers, and you often want different results
for an expression in a projection than when it's in a where clause for
example, which means that the handler has to know the scope it's in,
which is more complex to make maintainable than it looks at first.
I'm sure readers of my previous post will think that I'm just playing
the marketing trumpet, but I just want to make clear what the real state
of reality is regarding linq providers of some o/r mappers, not just
Linq to nhibernate: just because they can consume a from where select
construct doesn't mean it supports linq in full, and that's a problem,
because the last thing you want is when writing a query that you can't
write it the way you want it because it's not supported by the provider.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website:
http://www.llblgen.com
My .NET blog:
http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
So you can use linq to write queries or