OpAsQuery incorrect transform of dependent expressions about jena HOT 14 CLOSED

@Aklakan: Thank you for fixing that.

from jena.

Simpler: no ?y reuse for ?z:

SELECT ?z { BIND('x' AS ?y) BIND('z' AS ?z) }

from jena.

OpAsQuery is not a perfect reversal of the process of compiling the query to algebra. It aims to produce equivalent queries - same output. It has to spot patterns because SELECT (expr as ?var) and SELECT * { ... BIND (expr as ?var)} are the same algebra.

When translating algebra to syntax, OpAsQuery is spotting this pattern. If you want all the BIND, use SELECT *.

SELECT (?x AS ?y) (?y AS ?z) {} has two variables, whereas SELECT ?z {} has one. It's a different query.

from jena.

The problem is that the projection just naively filters the collected assignments without taking dependent expressions into account:

//OpAsQuery.java
level.opProject.getVars().forEach(v -> {
    if ( assignments.containsKey(v) ) {
        query.addResultVar(v, assignments.get(v)) ;
    } else
        query.getProjectVars().add(v) ;

}) ;

from jena.

It aims to produce equivalent queries - same output.

Yes, but in the first example with the transitive assignment of the constant 'x' it fails because the output differs.

In the case where there is a variable based off of a unit table it would be according to the 'same output' contract - though losing those expressions is not really what I expected.

from jena.

IMO the expected result.

I was speaking about this proposal. It is a different query.

This code has built-up over time with lots of opinion. Outputting a query that is not the input will probably cause users problems, generate a support load and we end up going in circles.

from jena.

Oh my, I messed up the expected results because I forgot the projection of ?z - sorry for the confusion.
Of course the output query should be the same as the input one.

I updated the expected results with the projection now.

from jena.

Why not add a detection criterion so that BIND is reversed to a project expression only if the project is safe? This would work down the (extend) stack with a "while safe" test. Replace that stream with a for-loop, push back remaining level.opExtends into the pattern.

These short examples hide the fact that in real queries, the BIND are at the end of a long pattern. Only BIND at the end are considered. Adding an extra sub-query - even if the same query - is unexpected by users.

from jena.

Why not add a detection criterion so that BIND is reversed to a project expression only if the project is safe?

Yes, that makes sense.

Adding an extra sub-query - even if the same query - is unexpected by users.

Certainly; I was incorrectly assuming that OpAsQuery due to the 'not perfect reversal'-nature always uses projections but I see it actually does support reversing into BIND. So the detection criterion is what is needed.

from jena.

It'll be easiest in the calculation of level.opExtend which look like it is processExtend (which is used twice).

from jena.

Are you working on it already or should I look into it? It's not clear whether your last message was a note to yourself or a hint to me :)

from jena.

I'm not working on it.

from jena.

Fixed by #1370.

from jena.

Also reported as JENA-2335.

from jena.