Type safe criteria

[Ayende Rahien]

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?


[Stephen Bohlen]

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.

[Fabio Maulo]

;)

A talk with the autor and I had review the prj before give him the ability to blog in NH-forge.

After NH2.1 we can add it in core (that mean soon).

2009/1/8 Ayende Rahien <aye...@ayende.com>

--
Fabio Maulo

[Fabio Maulo]

Ok Steve but in this case (NH-lambda-extension) the target is pretty clear : Completely avoid strings

2009/1/8 Stephen Bohlen <sbo...@gmail.com>

--
Fabio Maulo

[Stephen Bohlen]

Agreed. That's why I said I'm 100% in favor of this effort -- was just considering whether or not this would have any impact on the 'gimme LINQ' refrain :)

---

From: "Fabio Maulo"
Date: Thu, 8 Jan 2009 10:23:12 -0300
To: <nhibernate-...@googlegroups.com>
Subject: [nhibernate-development] Re: Type safe criteria

[Richard (Google)]

 

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: nhibernate-...@googlegroups.com

Subject: [nhibernate-development] Re: Type safe criteria

[Fabio Maulo]

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) <fluk...@googlemail.com>

--
Fabio Maulo

[Davy Brion]

this is indeed pretty cool, but i don't think anything is going to reduce the 'give us LINQ support' chants :)

--
Davy Brion
http://davybrion.com

[Ingo]

I agree with you. This is so much better when creating criterias.

However, I have an example that I don't think the current version can
handle (to my knowledge anyway)

ICriteria criteria = Session.CreateCriteria(typeof(UserInRole))
.Add(Expression.Eq
("ApplicationName", applicationName))
.Add(Expression.Eq("RoleName",
roleName))
.Add(Expression.InsensitiveLike
("UserName", userToMatch, MatchMode.Anywhere));

I think it has to be polished a bit before it can completely replace
the traditional criterias.

/Ingo

On 8 Jan, 10:52, "Ayende Rahien" <aye...@ayende.com> wrote:
> This is really interesting:
>

> http://nhforge.org/blogs/nhibernate/archive/2009/01/07/typesafe-icrit...

[Richard (Google)]

Oops, I missed that expression. I'll add it.

Also, I don't think it need to replace the existing criterias - it could
live along side them.

Richard

--------------------------------------------------
From: "Ingo" <ingemar.s...@gmail.com>
Sent: Friday, February 27, 2009 7:02 PM
To: "nhibernate-development" <nhibernate-...@googlegroups.com>

Subject: [nhibernate-development] Re: Type safe criteria

>

[similitude2009]

I want to had a note that is not exactly about type safe coding, but
more about getting rid of strings in criteria's.

It easy to write a code generator using refly (codedom based), or
erverything else that would make a static method for every property of
an entity class.

eg :
source file :

Public partial class Product
{
public virtual int Id {get;set}
public virtual string Name {get;set}
}

do something that will write a second code file like

Public partial class Product
{
public static string Id
(get {
return "Id";
}
)

public static string Name
(get {
return "Name";
}
)
}

Then in your Criteria, you could use

ICriteria criteria = Session.CreateCriteria(typeof
(Product),Product.Name)

ICriteria criteria = Session.CreateCriteria(typeof(Product),"Name")

Pro's : refactor friendly.

Con's : Need to recompile before use on neeed field creation.
Ugly hack.

On 28 fév, 11:40, "Richard \(Google\)" <fluke...@googlemail.com>
wrote:

> Oops, I missed that expression.  I'll add it.
>
> Also, I don't think it need to replace the existing criterias - it could
> live along side them.
>
> Richard
>
> --------------------------------------------------

> From: "Ingo" <ingemar.strandb...@gmail.com>

> >> Thoughts?- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -