DetachedCriteria : ICriteria

[Jan Limpens]

Is there a reason why DetachedCriteria does not implement ICriteria?

--
Jan
___________________
j...@limpens.com
www.limpens.com
+55 (11) 3082-1087
+55 (11) 3097-8339

[Tuna Toksöz]

Good question, I wonder it, too:)

--
Tuna Toksöz

Typos included to enhance the reader's attention ...

[Will Shaver]

DetachedCriteria is designed to be used for two purposes: 1) for setting up session-independent criteria 2) for setting up subqueries separate from standard queries.

 

For examples of both look in NHibernate.Test.ExpressionTest.Subqueries.SubQueriesSqlFixture

and NHibernate.Test.ExpressionTest.DetachedCriteriaFixture

 

As such they are specified without a session and if you attempt to use them without specifying the session they will fail. Standard Criteria are created by calling session.CreateCriteria which passes itself into the created criteria. Detached criteria are made without using the session object.

 

I think that this is a case of designing to protect the user instead of trusting the user, which I think is a good call in a framework like this. (Trusting the user would allow passing a DetachedCriteria as an ICriteria and would throw an exception if the Session wasn't specified.)

 

You can always call detachedCriteria.GetExecutableCriteria(session) to get at the actual criteria.

 

 -Will

[Dario Quintana]

One example: a DetachedCriteria can't implement a List() method because it is not associated to a session.

On Thu, Apr 3, 2008 at 5:20 PM, Tuna Toksöz <teh...@gmail.com> wrote:

Good question, I wonder it, too:)

On Thu, Apr 3, 2008 at 11:15 PM, Jan Limpens <jan.l...@gmail.com> wrote:

Is there a reason why DetachedCriteria does not implement ICriteria?

--

Dario Quintana
http://darioquintana.com.ar

[Ayende Rahien]

Yes, exactly

[Ken Egozi]

so leave .List() from ICriteria, and put it on IExecutableCriteria.

--
Ken Egozi.
http://www.kenegozi.com/blog
http://www.musicglue.com
http://www.castleproject.org
http://www.mamaherb.com
http://www.gotfriends.co.il

[Jan Limpens]

Ken Egozi wrote:
> so leave .List() from ICriteria, and put it on IExecutableCriteria.

I did not try out yet, whether the ICriteria returned
DetachedCriteria.GetExecutableCriteria(session) would allow me to alter
the original DetachedCriteria. That would suffice for my (current)
requirements. Anyways, if not so, a finer grained interface would help
me avoid redundancies in my code.
I'd personally would leave ICriteria as it is and provide a
ISetupCriteria for the current ICriteriaMethods minus List() and let
ICriteria inherit from it. But I am without good access to the sources
and have no idea if this would be possible.

Jan

[Fabio Maulo]

2008/4/3, Ken Egozi <ego...@gmail.com>:

so leave .List() from ICriteria, and put it on IExecutableCriteria.

Perhaps somebody may can explain why he need a future instead: "I want this because I want"

--
Fabio Maulo

[Jan Limpens]

On Fri, Apr 4, 2008 at 1:08 AM, Fabio Maulo <fabio...@gmail.com> wrote:
> Perhaps somebody may can explain why he need a future instead: "I want this
> because I want"

"He" being me, Jan (?):

I have a MultiCriteria of related criterias.
I return a set of products, that match a certain tree of criteria,
then a count of all products that match these criteria, then the
categories of the products, that match this criteria, then the
priceranges of all products that match this criteria and so on...
So all these criteria depend on a certain base criteria set to be
consistent. Sometimes I need create this tree for a ICriteria,
sometimes for a DetachedCreteria, so I have a

private static ICriteria getBaseProductsCriteria(int groupId, int
categoryId, PriceRange range, ICriteria criteria)

and a

private static DetachedCriteria getBaseProductsCriteria(int groupId,
int categoryId, PriceRange range, DetachedCriteria criteria)

the second being a real 1:1 copy of the first.

So I asked myself, why DetachedCriteria did not implement ICriteria
and got good reasons back.
What is a future? Did I say something offending I should not have?

[Ken Egozi]

the most convenient way could have been:

DetachedC baseCrit = ... //Create the specs

DetachedC countCrit = baseCrit.Clone()
  .SetProjection ...

DetachedC pagedCrit = baseCritClone()
  .///set the paging attributes

/// put both crits into the batch

[Fabio Maulo]

2008/4/4, Jan Limpens <jan.l...@gmail.com>:

the second being a real 1:1 copy of the first.

So I asked myself, why DetachedCriteria did not implement ICriteria
and got good reasons back.
What is a future? Did I say something offending I should not have?

Nothing offending nobody... but now the root of the matter is more clear.
I think that you are using DetachedCriteria from a wrong point of view.
DetachedCriteria and DetachedQuery are to leave users to write a more simple DAO and a more complex Model.
In practices DetachedCriteria and DetachedQuery represent the "parameters holder class" and give you an easy way to obtain the executable version of a query...

Take a look here:
http://code.google.com/p/unhaddins/wiki/LesTroisMousquetaires

In general if you have:

private static ICriteria getBaseProductsCriteria(int groupId, int categoryId, PriceRange range, ICriteria criteria)

you don't need an overload using DetachedCriteria

Bye.
Fabio Maulo

[Fabio Maulo]

2008/4/4, Fabio Maulo <fabio...@gmail.com>:

Take a look here:
http://code.google.com/p/unhaddins/wiki/LesTroisMousquetaires

I forgot something....
All uNhAddIns, not present in NH2.0.0Alpha1, was moved in NHibernate.Burrow.
Bye.
Fabio Maulo

[Jan Limpens]

On Fri, Apr 4, 2008 at 12:46 PM, Fabio Maulo <fabio...@gmail.com> wrote:
> In general if you have:
>
> private static ICriteria getBaseProductsCriteria(int groupId, int
> categoryId, PriceRange range, ICriteria criteria)
>
> you don't need an overload using DetachedCriteria

Olá Fabio,

I use these DeachedCriteria for In subqueries as I cannot do joins on
monodirectional relations with criteria. With hql this is possible,
with criteria I was not able to use joins in such situations.
I need to construct the query on runtime, so I preferred the Criteria
approach. The Dao is exposed to the controllers by a NHibernate
agnostic interface, but that has not been a problem for me so far.

[Luis Abreu]

Hello.

Yep, I've used this technique too with success in the past...

--
Regards,
Luis Abreu
email: labreu_at_gmail.com
PT Blog: http://weblogs.pontonetpt.com/luisabreu
EN Blog:http://msmvps.com/blogs/luisabreu/default.aspx
http://www.pontonetpt.com
MVP profile: http://mvp.support.microsoft.com/profile/luis.abreu

[Fabio Maulo]

2008/4/4, Jan Limpens <jan.l...@gmail.com>:

I use these DeachedCriteria for In subqueries as I cannot do joins on
monodirectional relations with criteria. With hql this is possible,
with criteria I was not able to use joins in such situations.
I need to construct the query on runtime, so I preferred the Criteria
approach. The Dao is exposed to the controllers by a NHibernate
agnostic interface, but that has not been a problem for me so far.

Perfect the use of Criteria.
But ..."agnostic interface" exposing ICriteria and DetachedCriteria ?

--
Fabio Maulo

[Jan Limpens]

On Sat, Apr 5, 2008 at 12:57 AM, Fabio Maulo <fabio...@gmail.com> wrote:
> But ..."agnostic interface" exposing ICriteria and DetachedCriteria ?

it's not exposed, but used only inside the dao