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
