[ 
https://issues.apache.org/jira/browse/JENA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437363#comment-16437363
 ] 

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
(v7.6.3#76005)

Reply via email to