[
https://issues.apache.org/jira/browse/JENA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794146#comment-13794146
]
Andy Seaborne commented on JENA-555:
------------------------------------
The call to {{QC.setFactory}} in {{TDB.wireIntoExecution}} should have been
unnecessary. It covers up a bug whereby {{StageGeneratorDirectTDB}} is not
adhering to the assumed naming of graphs used by {{SolverLib}} because
{{OpExecutorTDB}} is not used.
> Deprecate StageGenerators prior to removal.
> -------------------------------------------
>
> Key: JENA-555
> URL: https://issues.apache.org/jira/browse/JENA-555
> Project: Apache Jena
> Issue Type: Improvement
> Reporter: Andy Seaborne
> Assignee: Andy Seaborne
>
> StageGenerators are an old way of extending SPARQL query execution. It is
> better to extend OpExecutor (the general purpose algebra execution engine).
> OpExecutor calls the generic StageGenerator currently.
> # Remove StageGenerator from documentation on extending ARQ.
> # Extract the BGP execution into a library.
> # OpExecutor to directly call this library unless the context option is set.
> # Don't set the global context(key = ARQ.stageGenerator) with a
> StageGenerator.
> # Mark StageGenerator \@Deprecated
> # Update examples
> # Check TDB and SDB, esp TDB on single graphs.
> Important here is how a graph from one of those storage subsystems, when
> places in general purpose dataset with other graph types, still manages to go
> to the storage specific BGP execution. (Maybe this does not matter - if it
> misses it will fall back to using {{find()}} so always be correct.)
> We may been to retain the idea of a StageGenerator to catch the single-graph
> case but at least remove as a general extension point in favour of OpExecutor.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
