Allow selecting all variables as payload in spatial search SERVICE

[ullingerc]

In the spatial search service (triggered via SERVICE spatialSearch:) all variables from the right hand side of the join (except for the join column) that shall be part of the result have to be explicitly selected via the <payload> parameter. This PR adds a special value <all> for this parameter, which automatically selects all the variables from the right side as payload.

[codecov]

Codecov Report

Attention: Patch coverage is 96.70330% with 3 lines in your changes missing coverage. Please review.

Project coverage is 89.59%. Comparing base (44e2ba8) to head (50fee8c).
Report is 8 commits behind head on master.

Files with missing lines	Patch %	Lines
src/parser/PayloadVariables.h	57.14%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1656      +/-   ##
==========================================
+ Coverage   89.57%   89.59%   +0.02%     
==========================================
  Files         381      383       +2     
  Lines       36792    36863      +71     
  Branches     4170     4178       +8     
==========================================
+ Hits        32955    33029      +74     
+ Misses       2525     2522       -3     
  Partials     1312     1312              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[joka921]

I have thought of a way, to make the payload much simpler.

[joka921]

Thank you very much, only a very minor changes is missing.

[joka921]

Isn't the !isAll call redundant, because isAll() directly implies !empty() ?

[ullingerc]

I disagree. If I'm not totally mistaken, this is neither logically nor semantically redundant.

• Logically because isAll implies not-empty but not-empty does not imply isAll
• Semantically because there is a subtle edge case, where this has an actual impact: Assume the user does a max-dist-join and declares left and right outside of the service. Then they give the configuration <payload> <all>. This is the default behavior anyway. But without the !isAll() here we would throw despite the user's configuration just stating the default value.

Edit: I will add a unit test for the edge case.

[joka921]

Can you try whether the undefined reference errors go away when you move the PayloadVariable class into the parser module and make it part of the parser library?
We really have to cleanup our dependencies.

[ullingerc]

Can you try whether the undefined reference errors go away when you move the PayloadVariable class into the parser module and make it part of the parser library? We really have to cleanup our dependencies.

I have moved it. Let's wait for the checks and see what happens. The weird thing is that I cannot reproduce this problem locally...

[sparql-conformance]

Conformance check passed ✅

No test result changes.

Details: https://qlever.cs.uni-freiburg.de/sparql-conformance-ui?cur=218b1098df209adc4d744de87bbfcb768d9c0f9e&prev=ec806f0091babfdcb57b20189c7656337b3f7a71

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ullingerc]

@joka921 Thanks very much. This seems to have fixed it.

[joka921]

Thank you very much.