It does come with a SetLockMode extension, yes. No, it does not fix that, nor do I think it should. If locking in combination with projection should work, I think the best syntax would be
var result = (from e in db.Customers.WithLockMode(LockMode.Upgrade) where e.CompanyName == "Corp" select e.CustomerId).ToList(); But it doesn't work, not even with HQL or Criteria, and implementing it would be slightly tricky, since the only lockmode making any sense in such a scenario is LockMode.Upgrade (I guess). A separate JIRA issue, perhaps? /G 2015-09-29 12:36 GMT+02:00 Peter Schojer <[email protected]>: > That's the commit with the SetLockMode extension? I am already waiting for > this one :-) > > Does this additional patch also fixes the problem that setlockmode > currently only works on selecting "full" objects? > > See my comment on the JIRA Ticket NH-2140 where the following query fails: > var result = (from e in db.Customers where e.CompanyName == "Corp" select > e.CustomerId).SetLockMode(LockMode.Upgrade).ToList(); > > > > Am Montag, 28. September 2015 17:42:36 UTC+2 schrieb Gunnar Liljas: >> >> So, to keep the momentum going, any favored paths forward? I don't mind >> the ResultOperators that much, as long as they are removed. They do however >> become part of the expression cache key, unless a specifically ignored >> during that process. >> >> Also, it was encouraging to get a response to my question. I wish there >> was more activity (or at least more active communication) regarding NH core >> development. >> >> /G >> >> 2015-09-28 9:42 GMT+02:00 Gunnar Liljas <[email protected]>: >> >>> OK, interesting. A similar idea but a different approach. It does remove >>> the ResultOperators though, which is a fair compromise. >>> >>> /G >>> >>> 2015-09-28 8:33 GMT+02:00 Michael Ketting <[email protected]>: >>> >>>> Hi Gunnar! >>>> >>>> EntityFramework is going a similiar route with a >>>> QueryAnnotationResultOperator they use to collect the annotations. >>>> >>>> https://github.com/aspnet/EntityFramework/blob/dev/src/EntityFramework.Core/Query/Internal/QueryAnnotationExtractor.cs >>>> >>>> That's actually one of the ideas I'm thinking of adopting for re-linq's >>>> own SQLBackend, too. For now, the ResultOperators certainly are the easiest >>>> way to accomplish this. >>>> >>>> Best regards, Michael >>>> >>>> On Monday, September 28, 2015 at 7:38:33 AM UTC+2, Alexander Zaytsev >>>> wrote: >>>>> >>>>> Hi Gunnar, >>>>> >>>>> This looks very good. I think this can be simplified if we omit these >>>>> operations (cacheable, timeout, etc) from a query at all. >>>>> >>>>> I think this can be done by casting inside these methods (as EF does >>>>> sometimes) to the INHibernateQueriable (or similar interface) to set >>>>> options. >>>>> >>>>> What do you think? >>>>> >>>>> Best Regards, >>>>> Alexander >>>>> >>>>> On Mon, Sep 28, 2015 at 2:00 AM, Gunnar Liljas wrote: >>>>> >>>>>> Hi! >>>>>> >>>>>> I just made a commit (not a pull request, I'm not sure it's quite >>>>>> ready) with a new approach to query options in Linq queries. Instead of >>>>>> dealing with results operators for things that are actually not a part of >>>>>> the query, I made an expression visitor that extracts the query options >>>>>> from the query AND removes them. The options are applied to the parsed >>>>>> query. >>>>>> >>>>>> >>>>>> https://github.com/gliljas/nhibernate-core/commit/1655320149385c96c64fd56598e9253621ba0da9 >>>>>> >>>>>> There was one major hurdle, and that was to omit these options if >>>>>> they occur in a subquery. Currently the visitor solves this (or does it?) >>>>>> by detecting when the first chain of Call expressions is done, but of >>>>>> course it would be more convenient to use Relinq for this. But that >>>>>> happens >>>>>> later in the chain than currently feasible. >>>>>> >>>>>> It's more a proof of concept, so I would very much like some feedback. >>>>>> >>>>>> /Gunnar >>>>>> >>>>>> -- >>>>>> >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "nhibernate-development" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "nhibernate-development" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> -- > > --- > You received this message because you are subscribed to the Google Groups > "nhibernate-development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "nhibernate-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
