Well that's what I understood except that isn't what's implemented in the code. My sample query on the sample dataset should have failed with a query error if that was the case.
Following the code OpExecutor executes OpExtend by creating a QueryIterAssign and it sets the constructor parameter mustBeNewVar to true (https://github.com/apache/jena/blob/1cdaa70edd61c2fbba5777e8b2ec7bcaf90b7c75/jena-arq/src/main/java/org/apache/jena/sparql/engine/main/OpExecutor.java#L440-L446) BUT the implementation code at https://github.com/apache/jena/blob/31dc0d328c4858401e5d3fa99702c97eba0383a0/jena-arq/src/main/java/org/apache/jena/sparql/engine/iterator/QueryIterAssign.java#L73-L74 checks that flag in a false && mustBeNewVar condition so never enforces that requirement. Thus it continues onto the sameValueAs check at line 76 effectively meaning OpExtend and OpAssign are evaluated identically right now Rob On 02/12/2021, 18:13, "Andy Seaborne" <a...@apache.org> wrote: On 02/12/2021 09:31, Rob Vesse wrote: > Yes I did play around with some other forms and observed that the older assign form is still used for more complex forms > > I think the other confusion for me was that historically OpExtend evaluation would fail if the assignment variable already existed, but again digging into the code it looks like that restriction is no longer enforced. We have (extend) = BIND = OpExtend (assign) = LET(an extension) = OpAssign Still true that BIND will not allow redefinition nor reassign same value. It is a static condition done at algebra generation and static optimization. (assign) will allow redefinition if it is the same term (it is like FILTER sameTerm). Andy > > Rob > > On 01/12/2021, 18:27, "Andy Seaborne" <a...@apache.org> wrote: > > 4.2.0 change. > > https://issues.apache.org/jira/browse/JENA-2150 > > OpVars now processes BIND variables (an imporvement) and so optimizer > does generate the 4.2.0 form because it is a BIND. > > Different patterns have different forms: > > SELECT * { > GRAPH ?g { > ?s ?p ?o . > FILTER ( <http://graphs/1> = ?g ) > } > } > > ==> > > (assign ((?g ?*g0)) > (filter (= <http://graphs/1> ?g) > (quadpattern (quad ?*g0 ?s ?p ?o)))) > > because ?g is not in scope in the FILTER. > > Andy > > On 01/12/2021 11:20, Rob Vesse wrote: > > Hey Folks > > > > > > > > So I’ve been dragging some old code back up to date with Jena 4 and noticed an interesting behavioural change around quad form algebra generation and optimization that kinda took me aback when I first found it. I think the algebras are semantically equivalent but at initial glance I wondered whether there is a potential scoping issue here. > > > > > > > > Consider the following trivial dataset: > > > > > > > > <http://a> <http://b> <http://c> <http://graphs/1> . > > > > <http://d> <http://e> <http://c> <http://graphs/2> . > > > > > > > > And the following query: > > > > > > > > SELECT * > > > > WHERE > > > > { > > > > GRAPH ?g { > > > > ?s ?p ?o . > > > > BIND(<http://graphs/1> AS ?g) > > > > } > > > > } > > > > > > > > Obviously this is a somewhat odd query but it’s a simplification of the more general pattern of calculating the desired graph name inside of a GRAPH ?var block in order to produce only results from some subset of graphs > > > > > > > > When translate into quads form with Jena 3.x I get the following: > > > > > > > > (assign ((?g ?*g0)) > > > > (extend ((?g <http://graphs/1>)) > > > > (quadpattern (quad ?*g0 ?s ?p ?o)))) > > > > > > > > But with Jena 4.x I get this instead: > > > > > > > > (extend ((?g <http://graphs/1>)) > > > > (quadpattern (quad ?g ?s ?p ?o))) > > > > > > > > Note that in 3.x it rewrites the graph node in the inner quad pattern and uses assign to filter those after the extend but in 4.x it does not rewrite the graph node. While semantically these appear equivalent, and loading the test data into TDB 2 and uses tdb2.tdbquery to run a quad mode execution yields the same results in both cases, I do wonder if there’s a potential corner case here where scoping gets screwed up on more complex queries? > > > > > > > > It seems in general that Jena 4.x less aggressively rewrites the graph name when translating OpGraph into quads form and maybe that’s perfectly fine but just wanted to check if this was an intended change and whether anybody else had encountered this. > > > > > > > > For example rewriting the query to put the BIND first inside the GRAPH clause yields the following algebra on 3.x: > > > > > > > > (assign ((?g ?*g0)) > > > > (sequence > > > > (extend ((?g <http://graphs/1>)) > > > > (table unit)) > > > > (quadpattern (quad ?*g0 ?s ?p ?o)))) > > > > > > > > And on 4.x: > > > > > > > > (sequence > > > > (extend ((?g <http://graphs/1>)) > > > > (table unit)) > > > > (quadpattern (quad ?g ?s ?p ?o))) > > > > > > > > So again I think semantically equivalent but not rewriting the graph name. > > > > > > > > Any thoughts/opinions on this? > > > > > > > > Cheers, > > > > > > > > Rob > > > > > > > >
