[
https://issues.apache.org/jira/browse/JENA-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094229#comment-14094229
]
Rob Vesse commented on JENA-763:
--------------------------------
bq. Is the assumption that the quad transform is done first not reasonable in
some use case?
Opening access to {{TransformQuadGraph}} would probably be the simplest thing
to do I think particularly if it gives us the option to handle
{{transform(OpExt)}}
We are doing quad transform first but there are a number of more complex cases
where it does not work. In our particular scenario our custom operators are
added as additional modifiers to a query so we are overriding
{{compileModifiers()}} of the {{AlgebraGenerator}} and essentially doing the
following:
* Call {{super.compileModifiers}}
* Call {{Algebra.toQuadForm()}}
* Add our custom modifiers if applicable
The major complication comes in when there are sub-queries involved because we
found that you cannot apply the quad form transformation inside the sub-query
because then it won't respect the outer query {{GRAPH}} specifiers and compiles
to the wrong queries. Several of the sub-query compliance tests from the
SPARQL 1.1 test suite failed when we attempted to simply apply the quad
transform always e.g. {{sq01}}.
This means that our third step becomes the following - _Add out custom
modifiers if applicable *and not compiling a sub-query*_. So then if we have
our modifiers applied to a sub-query that part of the query gets compiled
without quad form transformation and when we finally reach the outermost query
we apply the quad form transform and because it has to pass through the custom
operators the state tracking gets detached and we get incorrect results
bq. Is this specific to quad transformation or is there another real case?
Right now the quad transform seems to be the only one affected because it is
the only one that needs external state AFAIK but it would be nice to have a
more generic solution that the quad transform could adopt that would be usable
by any other transforms that need this in the future.
> 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
>
> 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)
