ahhh....You remember me something.... Oren, that is the reason because in StatelessSession there is not CreateCriteria(System.Type).... When I implement StatelessSession I put only CreateCriteria<T>()... but if you need the overload go ahead.
2009/1/8 Richard (Google) <[email protected]> > > 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 <[email protected]> > *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? >> > > -- Fabio Maulo
