[
https://issues.apache.org/jira/browse/JENA-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Vesse closed JENA-763.
--------------------------
Confirmed that these changes allow us to resolve the problems with quad from
transform and our custom operators
Closing the resolved issue
> 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: Andy Seaborne
> Attachments: Jena673.java, Jena763-possibility-1.patch,
> Jena763_ExQuadTransform.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.3.4#6332)
