Andy Seaborne commented on JENA-555:

{{StageGenerator}}s will exist due to the custom graph in general datasets case 
and it is hard to see a better way to treat that situation. Closing the ticket.

> 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
>            Priority: Major
> 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

Reply via email to