On 28/11/11 18:22, Robert Vesse wrote:
Hey All

We're looking to disable TransformFilterEquality because for our
query engine it generates an algebra that we can't process (because
it uses extend and we only support SPARQL 1.0 operations currently).
Initially we just reversed the obvious part of this optimisation in
our Transform by turning extend back into filter = but we've now
noticed that TransformFilterEquality doesn't just switch filter for
extend but it actually substitutes the constant for the variable in
the inner algebra operations.  So when our engine hits the recreated
filter the variable in question doesn't exist so it blindly filters
everything out.

So having traced the code paths for optimization I can see that in
Optimize.rewrite() it applies a bunch of different optimizations
depending on what context symbols are set.   AFAICT it should be a
simple case of setting the symbol ARQ.optFilterEquality to be false

My concern is that in the last ARQ release this was marked deprecated
but in the latest trunk it is not so what is the actual status of
this switch?  We need to use it so we'd really like to see it stay in
ARQ

Rob,

There no plans to remove or change optFilterEquality but which version are you referring to?

In the last release (2.8.8) "filterPlacement" was marked deprecated with javadoc saying "use optFilterPlacement". The same is true in the current code. There was some renaming awhiel ago to put "opt" on the front of all switches.

2.8.8 (and 2.8.7, 2.8.6, 2.8.5, 2.8.4 !!)

    @Deprecated
    /** @deprecated Use optFilterPlacement */
    public static final Symbol filterPlacement = optFilterPlacement ;

    /**
     *  Context key controlling whether the standard optimizer applies
     *  optimizations to equalities in FILTERs.
     *  This optimization is conservative - it does not take place if
     *  there is a potential risk of changing query semantics.
     */
public static final Symbol optFilterEquality = ARQConstants.allocSymbol("optFilterEquality") ;

        Andy



Regards,

Rob Vesse


Reply via email to