Aklakan commented on PR #3511:
URL: https://github.com/apache/jena/pull/3511#issuecomment-3977653786
The precedence is:
```
SparqlAdapterRegistry.new{Query|Update}ExecBuilder
--falls back to-->{Query|Update}ExecDatasetBuilderImpl
--uses-->{Query|Update}EngineRegistry.
```
* The builders can intercept any SPARQL query form: select, ask, construct
and describe with quad variants, json.
* The engines operate below on the select query/Op and QueryIterator level:
`QueryEngineFactory -> Plan -> QueryIterator`.
Because of these different levels of abstraction I don't think it is a good
idea to pull query engine level machinery (especially the unwrapping system) up
to the builder level.
The sparql adapter / builder abstraction is to forward the whole sparql
statement (against a `DatasetGraph`) to a certain executor which provides its
own `{Query|Update}ExecBuilder` implementation. For example, the forward for
remote HTTP SPARQL endpoints.
For your question, I added a new `TestSparqlAdapterSystem` which introduces
a custom `DatasetGraphRef` class and
then uses the adapter system to use query builders that configure the
ref(erence) query engine.
For this to work, the provider `accept` and `create` methods now also have a
context argument - similat to `QueryEngineFactory`.
You may want to check whether this looks OK to you.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
