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.
