James Perhaps it is useful if I weigh in since what you are proposing to do sounds very like what we at Cray have been doing for several years now.
We have a system where the front ends are Java based and we use ARQ for the initial parsing of queries, translation into basic algebra and as part of our optimiser. The nice thing about the ARQ optimiser is that you can set flags which disable each optimisation so in our case we disable all the optimisations that generate non-standard algebra operators - these are the topn, sequence, conditional and disjunction which Andy already mentioned Relevant flags are: - ARQ.optIndexJoinStrategy - ARQ.optTopNSorting You set these to false in a ARQ Context object that you pass to the calls of Optimize.optimize() should you wish to use the ARQ optimiser. Of course if you don't wish to use the optimiser then you can override the modifyOp() method on your QueryEngine instance (assuming you start by extending QueryEngineBase) and not call the optimiser at all. Alternatively if you just want the "standard" algebra (i.e. the fairly true to spec, no optimisation version) then the basic Op structure generated by the AlgebraGenerator should be sufficient for your uses if you need just the algebra In our system we then translate the algebra (using a custom visitor) into a form that our backend understands and ship that across the network rather than serialising the algebra out to strings and re-parsing it elsewhere (we've done that in the past but performance and maintenance wise it proved much better to transform the algebra into something that could be processed directly by our back end). In terms of the stability of the algebra API I think there has only been 1 breaking change to the API in the time we've been using it and that was actually proposed by us and was necessary to resolve an interesting corner case bug involving the optimiser and custom algebra operators. Hope this helps, Rob On 16/01/2015 15:22, "james anderson" <[email protected]> wrote: > >On 2015-01-16, at 16:05, Andy Seaborne <[email protected]> wrote: > >> On 16/01/15 14:55, james anderson wrote: >>> as expected - so long as one does not change their approach to >>>argument order… >> >> Is there a place where ARQ does? It's not intended AFAIK. > >the are already some, for which our signature differs from arq’s, but >that is not the issue. >that is no different than that some of our operator names are not an >exact match to arq’s. >it would become an issue for us to track if arq were to change its >convention between version. > >best regards, from berlin >--- >james anderson | [email protected] | http://dydra.com > > > > >
