ASF GitHub Bot commented on JENA-1519:

Github user afs commented on a diff in the pull request:

    --- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/algebra/OpWalker.java ---
    @@ -139,6 +139,7 @@ protected void visitN(OpN op) {
             protected void visitExt(OpExt op) {
                 before(op) ;
    +            super.visitExt(op);
    --- End diff --
    There are probably both cases. Its an extension point so it is hard to be 
categorical. Only the effective is walkable unless the OpExt is comprised of 
known Ops in which case it does not need to be an OpExt.
    Let's leave it as per the PR - we might have to return to it but without a 
concrete alternative usage, it feels like slipping towards guessing.

> OpWalkerVisitor should interact better with custom operators
> ------------------------------------------------------------
>                 Key: JENA-1519
>                 URL: https://issues.apache.org/jira/browse/JENA-1519
>             Project: Apache Jena
>          Issue Type: Bug
>          Components: ARQ
>    Affects Versions: Jena 3.6.0
>            Reporter: Jeremy Coulon
>            Priority: Major
> When visiting an OpExt, current implementation of OpWalkerVisitor is just 
> calling the visitor on opExt.effectiveOp().
> However if OpExt is replacing a sub-tree of the algebra instead of a single 
> leaf node, the sub-tree is ignored by walker.
> I found this bug when trying to execute a query with a MINUS operator with 
> either side of the operator being replaced by an custom operator.
> For example the following query is not working, if I transform both side of 
> MINUS with a custom operator:
> {{(project (?animal)}}
> {{  (minus}}
> {{    (bgp (triple ?animal rdf:type ex:Animal))}}
> {{    (filter (|| (= ?type ex:Reptile) (= ?type ex:Insect))}}
> {{      (bgp (triple ?animal rdf:type ?type)))))}}
> which I transform into:
> {{(project (?animal)}}
> {{  (minus}}
> {{    (op-ext )}}
> {{    (op-ext )))}}
> The reason is that MINUS is calling OpVars.visibleVars() which does not walk 
> into the subop of the filter.

This message was sent by Atlassian JIRA

Reply via email to