Do that. As the discussion there indicates, it's not a simple issue.
— Sent from Mailbox On Wed, Sep 30, 2015 at 7:14 AM, Peter Schojer <[email protected]> wrote: > 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 <[email protected] >> <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 <[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] >>> <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 [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.
