Yes, your proposed syntax is closer to what the database generates, that would make more sense. there is already a similar JIRA issue but for criteria: NH-1968 <https://nhibernate.jira.com/browse/NH-1968>
Maybe simply update that ticket? Am Dienstag, 29. September 2015 23:16:19 UTC+2 schrieb Gunnar Liljas: > > 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 <peter....@gmail.com > <javascript:>>: > >> 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 <gunnar...@gmail.com>: >>> >>>> 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 <michael...@rubicon.eu>: >>>> >>>>> 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 nhibernate-development+unsubscr...@googlegroups.com >>>>>>> . >>>>>>> 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 nhibernate-development+unsubscr...@googlegroups.com. >>>>> 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 nhibernate-development+unsubscr...@googlegroups.com >> <javascript:>. >> 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 nhibernate-development+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
