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 <[email protected]> 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.
