Rob
On 02/12/2021, 18:13, "Andy Seaborne" <[email protected]> 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" <[email protected]> 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
> >
> >
>
>
>
>
