Don't use cache-max-size-lazy-result setting for the root operation, even when it's lazy

[RobinTF]

Since #1638, QLever has the runtime parameter lazy-result-max-cache-size, with a deliberately small default value of 5 MB. However, the final result (of the root operation) should be cached not depending on that size, but depending on the regular cache-max-size, cache-max-size-single-entry, and cache-max-num-entries, even if the last operation is (output-)lazy. This is now indeed so. Fixes #1701 (which provides a good example of a query, where the old behavior is weird and the new behavior makes much more sense).

Use the occasion to give the runtime parameter a more consistent name, namely cache-max-size-lazy-result.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.97%. Comparing base (aa55057) to head (7463a53).
Report is 4 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1709   +/-   ##
=======================================
  Coverage   89.97%   89.97%           
=======================================
  Files         395      395           
  Lines       37689    37703   +14     
  Branches     4241     4242    +1     
=======================================
+ Hits        33911    33924   +13     
  Misses       2479     2479           
- Partials     1299     1300    +1     

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

[hannahbast]

This looks good, thanks a lot for the quick fix! I tried it with the example query from #1638, and that works fine now. I have a small question about the test coverage but that might be void.

[hannahbast]

In the modified tests, isRoot is always false, so I wonder why CodeCov ist not complaining about incomplete coverage here.

[RobinTF]

So the reason why the test coverage is fine is because there are probably dozens of tests for classes inheriting from Operation, so at least one of them explores the other code path.
That being said, as you observed correctly the existing tests don't explicitly test this new behaviour, so we definitely should add a test that tests this explicitly.

[RobinTF]

@hannahbast I added the proper unit tests

[hannahbast]

Thanks a lot + this looks good + will merge this now

[sparql-conformance]

Conformance check passed ✅

No test result changes.

Details: https://qlever.cs.uni-freiburg.de/sparql-conformance-ui?cur=7463a538ec681ca2da84dc0ecc45166985e82f3b&prev=aa550575c990869a44bc469490c0371e77243b48

[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