[
https://issues.apache.org/jira/browse/JENA-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171055#comment-15171055
]
Andy Seaborne commented on JENA-1148:
-------------------------------------
The cause is that {{(conditional)}} and {{(sequence)}} are not pure evaluations
- they each rely the results of the previous item to be passed into the next in
the operator thereby exposing the earlier variables.
Moving the "Filter Equality" transform to just before "Index Join strategy" and
only test failures are the following ones from
TS_Optimization/TestTransformFilters:
{noformat}
TS_Optimization
org.apache.jena.sparql.algebra.optimize.TS_Optimization
org.apache.jena.sparql.algebra.optimize.TestTransformFilters
optionalEqualitySubQuery_01
Fails to do the equality replacement
optionalEqualitySubQuery_02
OK - different output - just as good
optionalEquality_01
Fails to do the equality replacement
optionalEqualityScope_01
Fails to do the equality replacement
optionalEqualityScope_02
OK - different output - just as good
{noformat}
> TransformFilterEquality incorrectly eliminates some optionals
> -------------------------------------------------------------
>
> Key: JENA-1148
> URL: https://issues.apache.org/jira/browse/JENA-1148
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Reporter: Eetu Mäkelä
> Labels: Optimization, sparql
>
> For a query of the form:
> {code}
> SELECT * {
> ?s ?p ?o
> OPTIONAL {
> FILTER(?o=<urn:x1>)
> BIND(true AS ?b)
> }
> }
> {code}
> ARQ optimization incorrectly eliminates the whole OPTIONAL when the variable
> filtered on does not appear elsewhere inside the OPTIONAL block . This is
> because of the special case check called on [line 120 of
> TransformFilterEquality.java|https://git-wip-us.apache.org/repos/asf?p=jena.git;a=blob;f=jena-arq/src/main/java/org/apache/jena/sparql/algebra/optimize/TransformFilterEquality.java;h=38ba84019ba3b446afd8106128c517913a7ef73e;hb=6908fb7b7a500a70edb314b4830a18ed02a6b0f8#l120],
> which sees that ?o is not used inside the block of the filter and thus (in
> this case incorrectly) deduces that it could never be <urn:x1>.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)