[
https://issues.apache.org/jira/browse/JENA-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Vesse updated JENA-763:
---------------------------
Attachment: Jena673.java
Attaching a minimal example that can be used to see the issue we are
experiencing. This simply requires putting into a project with an ARQ
dependency in order to be run.
Firstly it demonstrates the point I was trying to make about {{sq01}} - you can
see that when you have a custom algebra generator that adds a custom operator
around the query you have to perform the quadization only at the top level as
otherwise you generate incorrect algebra:
{noformat}
Normal Algebra:
(project (?x ?p)
(graph ?g
(bgp (triple ?x ?p ?y))))
Quad form Algebra:
(project (?x ?p)
(quadpattern (quad ?g ?x ?p ?y)))
Custom Algebra (immediate quadization => incorrect):
(foo
(project (?x ?p)
(foo
(quadpattern (quad <urn:x-arq:DefaultGraphNode> ?x ?p ?y))
))
)
Custom Algebra (top level quadization => correct):
(foo
(project (?x ?p)
(foo
(quadpattern (quad ?g ?x ?p ?y))
))
)
{noformat}
It then uses a custom test case to demonstrate an example query where the
inability of quad form transform to pass through the custom operator produces
an invalid algebra:
{noformat}
Normal Algebra:
(project (?x)
(project (?x)
(group (?x)
(union
(bgp (triple ?x <http://example.org/foo> 1))
(graph <http://example.org/graph>
(bgp (triple ?x <http://example.org/bar> 2)))))))
Quad form Algebra:
(project (?x)
(project (?x)
(group (?x)
(union
(quadpattern (quad <urn:x-arq:DefaultGraphNode> ?x
<http://example.org/foo> 1))
(quadpattern (quad <http://example.org/graph> ?x
<http://example.org/bar> 2))))))
Custom Algebra:
(foo
(project (?x)
(foo
(project (?x)
(group (?x)
(union
(quadpattern (quad <urn:x-arq:DefaultGraphNode> ?x
<http://example.org/foo> 1))
(quadpattern (quad <urn:x-arq:DefaultGraphNode> ?x
<http://example.org/bar> 2)))))
))
)
{noformat}
As you can see with the custom algebra generator involved the custom algebra
ends up incorrect - both {{quadpattern}} are accessing
{{<urn:x-arq:DefaultGraphNode>}} when one is supposed to access
{{<http://example.org/graph>}}
> Transforms should interact better with custom operators
> -------------------------------------------------------
>
> Key: JENA-763
> URL: https://issues.apache.org/jira/browse/JENA-763
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
> Affects Versions: Jena 2.12.0
> Reporter: Rob Vesse
> Assignee: Rob Vesse
> Attachments: Jena673.java
>
>
> As already discussed briefly on the mailing list thread How to safely apply
> transforms to custom algebra operators?
> (http://s.apache.org/custom-algebra-transform) making some transforms pass
> correctly through custom algebra operators.
> {{TransformCopy}} defers the {{copy(OpExt ext)}} implementation back to the
> {{apply()}} method of {{OpExt}} which means a custom operator can do
> something simple like the following:
> {noformat}
> @Override
> public Op apply(Transform transform)
> {
> // This is required in order to not block optimizations
> return new CustomOperator(Transformer.transform(transform,
> this.subOp), this.customParams);
> }
> {noformat}
> Which will work correctly for stateless transforms but fails for transforms
> like {{Algebra.toQuadForm()}} which rely on external state. In the specific
> case of quad form transformation the external state is tracked by before and
> after visitors that are applied as the {{ApplyTransformVisitor}} works down
> the algebra with the state being used by the actual transform as it comes
> back up the algebra. However when passed through a custom operator there is
> no way to pass through the external state trackers and so inside the custom
> operator the transform may be accessing incorrect state.
> There are a couple of options for fixing this:
> # Fix this specific case by rewriting the quad form transform such that it
> does not rely on external state tracking (not sure that this is even feasible)
> # Revise the API for transforming {{OpExt}} so external state can also be
> passed where necessary
> Both options have difficulties and it may be possible to make simpler changes
> that allow the specific case of quad form transformations to be fixed without
> changing the public API.
> Another approach would be to have the quad form transform be a public class
> and provided public accessors to its external state such that a custom
> operator could specifically recognise it and special case it such that the
> external state tracking was passed onwards. More generally perhaps a marker
> interface {{StatefulTransform}} could be added which would provide a standard
> way to recognise transforms that may have this problem and provide access to
> the state trackers necessary to pass these through custom operators
> correctly. Additionally there could be overloads of
> {{Transformer.transform(Transform)}} i.e.
> {{Transformer.transform(StatefulTransform)}} that would wire things up
> appropriately allowing the existing basic approach for custom operators
> outlined above continue to work without special cases.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
