Ouch!
I fear that I already removed all the Linq to NHibernate stuff, so I
cannot provide you the exact query...
Anyway, here's more less what I got:
First case (Hql)
select USER.FIRST_NAME,
USER.LAST_NAME,
...
USER.ID
from USER
where USER.SITE_FK = :SiteId
Second case (Linq2Hibernate)
select USER.FIRST_NAME,
USER.LAST_NAME,
...
USER.ID,
SITE.NAME,
SITE.CODE,
...
SITE.ID
from USER
left outer join SITE
on USER.SITE_FK = SITE.ID
where SITE.ID = :SiteId
Notice that, in addition to the join, the select list of the second
query includes all fields of both entities.
This could be avoided adding an ad-hoc IProjection to the ICriteria,
but the most annoying problem is really the join.
I don't even know if the related entity (in this case Site) gets
really created (and cached) or if the fields of Site are completely
ignored.
In the first case, it's like having a compulsory fetch! not even bad
in many scenarios, but it would be great to be able to turn it off.
In the second case (if the fields of the related entity are ignored)
it's really just a waste of resources.
It's really a pity because I find the Linq to NHibernate project
really great and I'm very impatient to be able to use it.
Still, I'm quite convinced that is a problem inherent in ICriteria.
Do you have suggestions?
On 15 jan, 19:19, Ayende Rahien <[email protected]> wrote:
> Please post the relevant SQL in both cases.
>
> On Thu, Jan 15, 2009 at 12:39 PM, Gabriele Tassi
> <[email protected]>wrote:
>
>
>
> > Hello everybody,
>
> > this is my first post in this group and I wonder if anybody has
> > experienced this same problem.
>
> > I'm working on a NHibernate-based project and I wanted to play a
> > little with Linq to NHibernate, from NHibernate Contrib.
>
> > So I happily integrated it in my system and turned some existing Hql
> > queries into Linq expressions.
> > Just as a simplified example: let's say that I had this function...
>
> > IEnumerable<User> GetUsers(ISession Session, long SiteId)
> > {
> > return Session.CreateQuery(@"
> > select User
> > from User User
> > where User.Site.Id = :SiteId
> > ")
> > .SetInt64(":SiteId")
> > .Enumerable<User>();
> > }
>
> > What I did is to turn it in this form:
>
> > IEnumerable<User> GetUsers(ISession Session, long SiteId)
> > {
> > return
> > from User in Session.Linq<User>()
> > where User.Site.Id = SiteId
> > select User;
> > }
>
> > In order to check that everything was ok, I turned on Sql Profiler to
> > examine the generated Sql query.
>
> > Here I noticed that query lacked an important optimization that is
> > normally present when you create a query using Hql.
>
> > In the first case the generated Sql query contains no join between
> > User and Site and the expression [UserClient.Site.Id] is replaced
> > (roughly) by [USER.SITE_FK].
>
> > In the second, sadly, no optimization and a nasty and useless join.
>
> > This example is a simplified version of my real case, in which I had 3
> > joins completely without purpose!
>
> > I went through the code of Linq to NHibernate and I realized what
> > maybe you all already know, that is that it is implemented using the
> > ICriteria objects. Now, from further tests, it seems to me that it's
> > the Criteria system that lacks this optimization: every reference to
> > related entities, even just to retrieve the id, lead to a join.
>
> > Does anybody of you have thoughts to share about this?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---
