Subquery Bug with `GROUP BY` and Variable Bindings in Corese Kernel

[remiceres]

Olivier identified a bug in the Corese kernel, occurring when using subqueries with a GROUP BY clause and passing variable bindings. The issue arises because executing the triple ?x ns:p ?y either before or after the subquery produces inconsistent results.

Reproduction Steps:

1. Query:

   prefix ns: <http://ns.inria.fr/test/>
   
   select * where {
       ?x ns:p ?y
       {
           select ?x (count(*) as ?c)
           where {
               ?x ns:q ?z
           } group by ?x
       }
       #?x ns:p ?y
   }

2. Dataset:

   prefix ns: <http://ns.inria.fr/test/>
   
   ns:a ns:p ns:b .
   ns:c ns:q ns:d .

Proposed Fix:

Olivier suggests modifying the queryNodeList function in the Exp class to resolve the issue by adjusting the handling of node lists when subqueries are involved.

void queryNodeList(ExpHandler h) {
    List<Node> selectList    = h.getSelectNodeList();
    List<Node> subSelectList = getQuery().getSelect(); //getSelectNodeList();
   
    if (h.isInSubScope()) {
        // focus on left optional etc. in query body
        // because select * includes right optional etc.
        List<Node> scopeList = getQuery().getBody().getTheNodes(h.copy());
        for (Node node : scopeList) {
            if (subSelectList.contains(node)) {
                if (! contain(getQuery().getGroupBy(), node)) {
                    add(selectList, node);
                }
            }
        }
    } else {
        for (Node node : subSelectList) {
            if (! contain(getQuery().getGroupBy(), node)) {
                add(selectList, node);
            }
        }
    }
}

Possible Side Effects:

This fix may impact performance, as it prevents passing the binding of the GROUP BY variable (in this case, ?x), which could lead to reduced optimization.

I also noticed that the testLetQuery in TestQuery1 fails with a StackOverflow error after applying this change. Further analysis is needed to evaluate the consequences of this modification.

[remiceres]

Résolu dans Corese Next : dans le nouveau pipeline SPARQL (PR #565 / #611), l’évaluation des sous-requêtes s’exécute dans un scope isolé et la jointure avec les motifs englobants respecte la sémantique W3C indépendamment de l’ordre des clauses. Test de non-régression validé dans NextSparqlPipelineAggregateExecutorTest.