Hi Claus,
Fancy implementations can be provided - the mechanism is to provide
QueryEngineFactory (which is an interface). The system takes a query
and a daatset and asks each registered QueryEngineFactory if it will
handle the query. The first one to say "yes" gets to execute the query.
The general purpose query engine is last on the last on that list.
https://svn.apache.org/repos/asf/jena/trunk/jena-arq/src-examples/arq/examples/engine/MyQueryEngine.java
This how TDB and SDB extend ARQ. They look for datasets of a given type.
(They both also implement Graph and are able to execute queries on
single graphs so you can have a mixture of graph storage types in one
dataset. That isn't required.)
Proving this through a fixed QueryExecutionFactory means that once init
code runs, there isn't an issue of finding the QueryExecutionFactory.
But if you want to provide something that replaces even QueryExecution
then maybe we can find a way within the current style of looking for
factories. This woudl then not disrupt people's code.
QueryExecutionFactory.make(Query, Dataset, Context) would look for
QueryExecution creators using one that did the current
QueryEngineFactory+QueryExecutionBase thing.
If you need more than QueryEngineFactory, please raise a JIRA to discuss
this ... details matter :-) when avoiding disturbing existing code.
Andy
PS You may be interested in Stephen's
https://svn.apache.org/repos/asf/jena/Experimental/jena-client/
Not the same but maybe of interest.
On 07/06/13 12:52, Claus Stadler wrote:
Hi,
Would it be possible to add a QueryExecutionFactory (QEF) *interface* to
Jena?
The com.hp.hpl.jena.query.QueryExecutionFacotry has lots of static
factory methods, but I guess it would be very useful if Jena itself
provided such an interface (either different package, different name or
both) because
then implementations based on Jena could rely on such interface (see
below and [1]) in a (quasi) standard way, and other projects could
provide fancy implementations.
public interface QueryExecutionFactory
extends QueryExecutionFactoryString, QueryExecutionFactoryQuery
{ /** * Some Id identifying the SPARQL service, such as a name given to
a jena Model or the URL of a remote service */
String getId(); /** * Some string identifying the state of this
execution factory, such as the selected graphs, or for query federation
the configured endpoints and their respective graphs. * Used for caching */
String getState();
}
The reason I ask this, is because I created [2], which uses this
architecture to transparently add delay, caching and pagination to a QEF
- i.e. you could just pose a usual SPARQL query to DBpedia, and [2] will
take care of retrieving the *complete* result, thereby caching each page
so that one can resume pagination from cache should something go wrong.
But for example, someone might provide a parallel pagination component,
or some query federation system, such as FedX could be wrapped with such
interface as well, and application developers would not have to rely on
a specific implementation.
Cheers,
Claus
[1]
https://github.com/AKSW/jena-sparql-api/blob/master/jena-sparql-api-core/src/main/java/org/aksw/jena_sparql_api/core/QueryExecutionFactory.java
[2] https://github.com/AKSW/jena-sparql-api
