[
https://issues.apache.org/jira/browse/JENA-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Vesse updated JENA-763:
---------------------------
Description:
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 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 (or even
just overloads of {{Transformer.transform(Transform)}} that would wire things
up appropriately.
was:
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. For example if the quad form transform was a public
class and provided public accessors to its external state 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 (or even
just overloads of {{Transformer.transform(Transform)}} that would wire things
up appropriately.
> 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 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 (or
> even just overloads of {{Transformer.transform(Transform)}} that would wire
> things up appropriately.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
