BQL: Support for optional clauses with default values about badwolf

[xllora]

Thanks for filing the issue @ikarennina.

The SPARQL standard has a provision to specify OPTIONAL clauses. Given your description, it is safe to assume constraints are not a concern, but multiple optional clauses are.

Adding only the OPTIONAL part only may require changes to the whole stack (lexer, parser, planner, and executor) but does not require changes to the driver interface; the resolution and orchestration is all done by the planner and executor in memory. Constraints, however, would likely require changes on the driver interface, hence I am going to say it is safe to leave them out of scope for now.

The proposed change would allow to mark clauses with the OPTIONAL. The example adapted the syntax from the SPARQL documentation to BQL. It also shows the benefits on a reified query

  SELECT ?user, ?label, ?score 
  FROM ?social_graph
  WHERE {
    ?bn "_subject"@[] /user<Joe> .
    ?bn "_predicate"@[] "follows"@[] .
    ?bn "_predicate"@[]  ?user .
    ?bn "tag"@[] ?label .
    ?bn "score"@[] ?score
  };

The above example would only return row where all three binding (?user, ?label, ?score) can be resolved. If for some reason the "tag@[] or score@[] predicates are not present, you would not get results back for those users. The use of OPTIONAL on those last two clauses would return all the folks that /user<Joe>, regardless if those clauses could be binded ore not. The new query would look like as:

  SELECT ?user, ?label, ?score 
  FROM ?social_graph
  WHERE {
    ?bn "_subject"@[] /user<Joe> .
    ?bn "_predicate"@[] "follows"@[] .
    ?bn "_predicate"@[]  ?user .
    OPTIONAL { ?bn "tag"@[] ?label } .
    OPTIONAL { ?bn "score"@[] ?score}
  };

@ikarennina would this extension help you address your use case?

[ikarennina]

Yes, that's exactly what I need. I suppose that in the absence of label and score they would contain some kind of null value?

[xllora]

Correct. The results table right now allows to return a *Cell where no values are set. That is you would get on the case that the binding on an optional clause. A *Cell without any pointer set is what you would get for OPTIONAL that did not bind.

[xllora]

Current changes are done all the way to the execution of the plan. At this point I need to revisit the execution itself and how the data gets merge on the presence of optional clauses. @ikarennina this may take me a few weeks given the shoestring bandwidth right now 🙃 .

[xllora]

Changes have been working as described originally in this issue. Closing it for now.