hartig
commented
2 months ago Implementation idea: Implement a new class called ExecOpBindJoinSPARQLwithVALUESorFILTER as a subclass that extends BaseForExecOpBindJoin<SPARQLGraphPattern, SPARQLEndpoint>. In its implementation of the _process function, at the first call of this function, the class first uses an instance of ExecOpBindJoinSPARQLwithVALUES and calls the process function of that instance. If this call succeeds without throwing an exception, then the new class continues using that instance for all subsequent calls to its _process function. If an exception occurs, however, then the new class replaces the instance of ExecOpBindJoinSPARQLwithVALUES by an instance of ExecOpBindJoinSPARQLwithFILTER, repeats the previously failed call (now using the process function of the filter-based operator), and then continues using the filter-based operator for all subsequent calls to its own _process function.
A unit test needs to be added that tests this functionality of either staying with the values-based instance or switching from the values-based instance to the filter-based one.
While the VALUES-based bind join algorithm is the most efficient one among the three SPARQL-related bind join algorithms, not all SPARQL endpoints support SPARQL 1.1 with the VALUES keyword. Currently, if we use the VALUES-based bind join and have such an endpoint in the federation, we would get an error and, then, produce an incomplete query result. Therefore, the current default is to always use the FILTER-based bind join instead.
To be able to benefit from the VALUES-based bind join, it would be useful to have a version of this algorithm that can automatically fall back to using a FILTER-based bind join in the cases in which the first request with the VALUES clause fails.