Re: [rdf4j-dev] 2 questions

["Jeen Broekstra" <jeen@xxxxxxxxxxxx>]

On Thu, 24 Nov 2022, at 03:29, Matthew Nguyen via rdf4j-dev wrote:

Hey folks, debugging some things and noticed the following that I wanted to get a take on:

1. Some of these optimizers are eating the exceptions (eg https://github.com/eclipse/rdf4j/blob/c607df2ace72eba12d6a3f9586b7fec4b8886129/core/queryalgebra/evaluation/src/main/java/org/eclipse/rdf4j/query/algebra/evaluation/impl/ConstantOptimizer.java#L248).  Do we want that?  So if I pass in an unregistered function, shouldn't the exception bubble up here?

The thinking here is that the optimizer _attempts_ to change the query plan and fails, leaving the query plan unchanged. The optimizer failing should not lead to an immediate error however: it's possible that somehow the query can still be executed successfully. That's why the optimizers generally swallow exceptions.

you can test it with against 4.2.1 workbench:

PREFIX fn: <http://example.com/>

SELECT ?whatever

WHERE {

BIND (fn:whatever("foo") AS ?whatever)

}

and it just silently fails.

Interesting find! I don't think that's caused by the optimizer swallowing the exception though. If you look at the server logs you will see that it actually does log that an exception during query execution:

org.eclipse.rdf4j.query.QueryEvaluationException: Unknown function 'http://example.com/whatever'

at org.eclipse.rdf4j.query.algebra.evaluation.impl.StrictEvaluationStrategy.lambda$evaluate$0(StrictEvaluationStrategy.java:1524)

at java.util.Optional.orElseThrow(Optional.java:290)

at org.eclipse.rdf4j.query.algebra.evaluation.impl.StrictEvaluationStrategy.evaluate(StrictEvaluationStrategy.java:1524)

at org.eclipse.rdf4j.query.algebra.evaluation.impl.StrictEvaluationStrategy.evaluate(StrictEvaluationStrategy.java:1060)

at org.eclipse.rdf4j.query.algebra.evaluation.iterator.ExtensionIterator.convert(ExtensionIterator.java:47)

at org.eclipse.rdf4j.query.algebra.evaluation.iterator.ExtensionIterator.convert(ExtensionIterator.java:23)

...

Also if you run the query directly on a local repository (e.g. by using the Console client) it fails "normally" with the same exception.

So this looks like a potential bug in how the server sends evaluation errors back to the workbench (or possibly how the workbench handles receiving such errors).

2. should we normalize these calls to the ValueExpr derived classes so we don't have these large if instanceOf/else checks (eg https://github.com/eclipse/rdf4j/blob/7fc970aa1fe27308bb44ec20d106e56e6353fdc9/core/queryalgebra/evaluation/src/main/java/org/eclipse/rdf4j/query/algebra/evaluation/impl/StrictEvaluationStrategy.java#L919)?  Looks like we would need one for evaluation/prepare if I'm reading this right.  So something like:

expr.acceptEval(this, bindings) and expr.acceptPrepare(this, context)

and the derived classes would just call the appropriate evaluate/prepare through the accepted 'this' object.  Would save a few cycles on the if/else checks I would think.  Also a little cleaner/less casting and any new _expression_ class would need to implement it if these were made abstract in the base and less likely to break b/c we forgot to add the corresponding if/else check.

This would probably be a good idea - however I haven't fully thought through if/how this would potentially lead to stronger coupling between between the algebra and the evaluation strategy. I believe the original intent of the setup (back at the dawn of time) was that the algebra model itself would be kept fully independent from the evaluation strategy - that's probably why it's set up the way it is (either that or we simply didn't know better :)).

Whether that intention to keep these things decoupled still makes sense though is a fair question.

Jeen