Github user afs commented on the issue:
https://github.com/apache/jena/pull/95
That's possible though they come into existence a bit late in the process
of setting up the query.
That are quite a few of possibilities up to an including making
`QueryExecutionFactory` have a policy object where all the internal calls like
`makePlan` become calls to a singleton object.
For local:
`QueryEngineFactory` is the interface - it can choose to handle a request
or not via `accept` so a policy on what to cache is possible, (e.g. some
datasets not others, some queries no others). It would accept whether it has it
cached or will cache it and call back into setup.
That might be special code in `QueryEngineRegistry.find`, a special policy
for `QueryExecutionFactory`
Or maybe as part of `QueryExecutionFactory.makePlan` looking aside to the
cache or adding `QueryEngineFactory` to the usual dispatch chain. That seems
cleaner in some ways but it'll need a way to to allow it to also call the
`QueryEngineRegistry` to find the factory that will actually produce new
results else it'll loop on the recursion.
A note of caution: the dispatch chain does get modified to add and remove
the reference query engine for example.
For remote:
To support Fuseki, we don't need remote caching.
The remote case and the local case follow different paths but again a
singleton policy at `QueryExecutionFactory.createServiceRequest/3`
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
