It would be nice to see a 3.5 release of NH with this kind of syntax out the
box.
I was originally planning on adding an ICriteria<T> (and DetachedCriteria<T>)
to the extensions project. The only reason I avoided it in the first release
was because the associations can't enforce the type correctly (that I can see)
...
session.CreateCriteria<Person>()
.CreateCriteria<ChildrenTypeMustGoHere>(p => p.Children) // nothing to
prevent wrong type
.Add(c => c.ChildName == "foo")
...
I might still look at adding it if it's going to be a while before an NH 3.5
release. (Obviously if you're gonna have this in a NH 3.5 release soon then
the extensions project will become obsolete anyway.)
In addition, as much as I love the idea of LINQ, I think it might help people
to be aware of how to sort problems like locking, and select n+1, with a LINQ
provider.
From: Stephen Bohlen
Sent: Thursday, January 08, 2009 12:00 PM
To: [email protected]
Subject: [nhibernate-development] Re: Type safe criteria
First, I'm all for this. Over the recent past, others (including myself) have
tinkered with variations on just such an approach...
http://www.kowitz.net/archive/2008/08/17/what-would-nhibernate-icriteria-look-like-in-.net-3.5.aspx
http://bugsquash.blogspot.com/2008/03/strongly-typed-nhibernate-criteria-with.html
http://unhandled-exceptions.com/blog/index.php/2008/11/22/the-continuing-quest-for-death-of-string-literals-in-my-code/
...with some of us going farther than others (e.g., my musing never lead to
anything fully-featured, but instead just languished as a quick spike on my HD).
It sort of seems to me like there are two (largely orthogonal) concerns here:
1) remove the dependence on string-literals in ICriterion queries
2) LINQ provider for NH
#1 is IMHO an entirely worthwhile goal in its own right -- clearly the less
magic, refactor-proof strings there are the better off we all are. I would
guess that there are some issues with how this would find its way into the NH
trunk since presently NH 2.1 has a publicly-stated desire to continue to target
Fx 2.0 and we need Fx 3.x for lambda support AFAIK (an implementation detail
that could be solved by introducing some kind of NH3xExtensions.dll assembly or
something similar to that, so not a deal-breaker by any means of course but
rather just an acknowledgement of some add'l complexity).
But as for #2, to me this gets to the heart of WHY people would want a LINQ
provider -- if its to get intellisense during the construction of queries, then
I think this would definitely help alleviate some of that pressure as you
suggest. But if its so that people already familiar with LINQ can move
laterally from their present DAL-of-choice to NH, then I don't entirely see how
this would help reduce that pressure (since knowing LINQ wouldn't ease the
coming-to-NH learning curve).
Maybe its worth re-evaluating WHERE the frequent requests for LINQ support are
coming from to try to futher investigate their 'motives/goals' which might help
us better understand the relative value of this 'alternate' approach...? Is is
people who ALREADY know NH and are looking for a more refactor-friendly way to
construct queries or is it from non-NH-users who are looking to flatten their
learning curve when approaching NH? Or is it from present NH-users who are
looking to spread it to the rest of their team/company/whatever and are
considering that LINQ2NH would make that process easier --? If we knew better
their goals, we might be better able to evaluate the effectiveness of pursuing
this 'intermediate' step.
FWIW, I would consider that this is (or something very much like it) would be a
valuable introduction to NH regardless of whether it materially reduces the
calls for a complete LINQ2NH provider -- clearly its something that myself and
others (including the initially-referenced poster) have been thinking about for
some time.
Other thoughts?
-Steve B.
On Thu, Jan 8, 2009 at 4:52 AM, Ayende Rahien <[email protected]> wrote:
This is really interesting:
http://nhforge.org/blogs/nhibernate/archive/2009/01/07/typesafe-icriteria-using-lambda-expressions.aspx
Expanding the syntax a bit, we can use:
session.CreateCriteria<Person>()
.SetFetchMode(p => p.PersonDetail, FetchMode.Eager)
.SetLockMode(LockMode.Upgrade)
.Add(p=>p.Name.Like("foo"))
.List();
That would remove a lot of the pressure to build a full fledged linq provider.
And it seems like it is much easier to do.
Thoughts?
