Allow unbound variables in compliance with the SPARQL standard

[joka921]

So far, QLever reported an error when an unbound variable was used in a GROUP BY, ORDER BY, or at other places, where an unbound variable does not really make sense. However, the SPARQL standard allows this. For example, SELECT * WHERE { ?s ?p ?o } GROUP BY ?doof is allowed by the standard and the correct result is a table with a single column ?doof but no results.

With this change, QLever complies to the standard regarding unbound variables at all kinds of places. Since queries like the above are often due to a typo in the query, we add a warning to the application/sparql-results+qlever results, which, in particular, is displayed in the QLever UI.

Additionally, there is a new runtime-parameter and associated command-line argument --throw-on-unbound-variables which reinstates the old behavior and reports an error instead of just a warning.

Fixes #1575

[codecov]

Codecov Report

Attention: Patch coverage is 99.09091% with 1 line in your changes missing coverage. Please review.

Project coverage is 89.31%. Comparing base (77ac964) to head (0242875).
Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/engine/Operation.h	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1586      +/-   ##
==========================================
+ Coverage   89.24%   89.31%   +0.06%     
==========================================
  Files         374      374              
  Lines       35315    35376      +61     
  Branches     3988     3997       +9     
==========================================
+ Hits        31518    31595      +77     
+ Misses       2503     2491      -12     
+ Partials     1294     1290       -4     

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

[aindlq]

Would it be possible to keep the current behavior behind some flag? I find it extremely useful that qlever rejects rubbish queries. It saved me a lot of time already. So it would be a pity to loos this functionality.

[joka921]

@aindlq Thanks for the input and the (in my opinion very reasonable) request.
I hope that I can find a way to get both behaviors with a reasonable amount of implementation work.

[aindlq]

For example for queries like in the linked issue, where group by uses non bound variable. It doesn't make any sense to return results, because clearly the query is wrong. I understand the use case of being a bit more relaxed and don't fail hard on broken queries, but most of the time when developing applications with SPARQL I want broken queries to fail hard, so I can actually fix them.

Sorry for the rant, but I believe that at this point this feature saved me countless hours of debugging. Because if query fails, I check qlever logs and immediately see what is the problem.

[hannahbast]

1-1 with Johannes, this looks great, adding some minor changes of mine in a subsequent commit

[hannahbast]

Looks great now, I will add a description + once everything is green merge this!

[sparql-conformance]

Conformance check passed ✅

Test Status Changes 📊

Number of Tests	Previous Status	Current Status
18	Failed	Passed
5	Failed	Intended

Details: https://qlever.cs.uni-freiburg.de/sparql-conformance-ui?cur=0242875d5df5c177f7e9a0ef3e18b9493ac8ed2f&prev=77ac964e9de37c10142bc19735d19fbb0c02ccc6

[sonarqubecloud]

Quality Gate passed

Issues
0 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

[hannahbast]

Thanks a lot for the final fix + I tested it end-to-end and it works fine + will merge this now!

[aindlq]

@joka921 Thank you for the --throw-on-unbound-variables flag!