If, instead HqlQueryPlanCache and all other stuff HQLxyz, we have: IQueryPlanCache IQueryPlan IQueryPlanKey <= only for IEquatable
and implementations for HQL (string based), Filters(string based *for now*), SQL(string based) and LINQ; in the implementation for LINQ we can avoid strings. Thoughts ? 2009/11/28 Steve Strong <[email protected]> > The expression trees processed by the new provider already are being cached > through the HqlQueryPlanCache :) > > On the first execute of a line query there's quote a lot of work done, but > on subsequent hits it's just a simple tree walk to build a key and extract > parameter values; everything else is already cached. > > Sent from my iPhone > > On 28 Nov 2009, at 00:20, Fabio Maulo <[email protected]> wrote: > > More than HQLQueryPlan I think we should "abstract" the QueryPlanCache. > > Would be SPECTACULAR if we can avoid multiple visit to the same > LINQ-ExpressionTree as we are avoiding multiple parse of the same > HQL-string. > > Have a look to QueryPlanCache and you will see we having zero abstraction > of HQLQueryPlan, FilterQueryPlan, > NativeSQLQueryPlan, HQLQueryPlanKey, FilterQueryPlanKey (I know you have > worked on it). > > 2009/11/27 Steve Strong < <[email protected]>[email protected]> > >> Hi All, >> >> Quick question - within HQLQueryPlan, HQL strings are parsed to >> determine polymorphic queries, hence potentially creating multiple >> translators for a single HQL query (such as "from System.Object o"). >> >> This is currently a fairly nasty bit of string processing code which >> is performed prior to making potentially multiple calls to the >> QueryTranslatorFactory, and this processing is performed the same way >> regardless of whether we are using the old translator or the new ANTLR >> based one. >> >> With the Linq provider, I obviously don't have an HQL string on which >> to run the existing processing, so I need to write code to process the >> tree to work out the polymorphic stuff (which is pretty simple, should >> be much cleaner than the existing string-based code). >> >> My plan is to refactor QueryTranslatorFactory so that the decisioning >> around polymorphism resides in there rather than in the >> HHQLQueryPlan. That way, the current string based code will move into >> the classic parser, and the tree-based code that I need to write for >> Linq will move into the ANTLR parser and be used for both Linq and >> string-based HQL when that parser is being used. HQLQueryPlan will >> just make one call to the QueryTranslatorFactory rather than the >> multiple calls that it may make, with the refactored >> QueryTranslatorFactory returning a list of translators rather than the >> single translator that it currently returns. >> >> The question is just to see if anyone sees any issues with that? As >> far as I can see, it's a pretty isolated change but just wanted to >> bounce it of you chaps before getting the scalpel out :) >> >> Cheers, >> >> Steve >> > > > > -- > Fabio Maulo > > -- Fabio Maulo
