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]>
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
