The contrib linq is not optimized, so that is not surprising.Try to use Criteria directly for that, and we can inspect the results better
On Thu, Jan 15, 2009 at 1:40 PM, Gabriele Tassi <[email protected]>wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
