Sparql Adapter System

[Aklakan]

Version

5.7.0-SNAPSHOT

Feature

This is the proposed sub system upon which execution tracking for both local and remote datasets can be based.

SparqlAdapterRegistry

The core idea is to introduce an indirection for sparql query and update execution. The central class is SparqlAdapterRegistry which is a container for SparqlAdapterProvider instances:

public interface SparqlAdapterProvider {
    SparqlAdapter adapt(DatasetGraph dsg);
    // Perhaps rename to "createAdapter" to avoid confusion with "adapt" methods in presentation layer classes.
}

public interface SparqlAdapter {
    QueryExecBuilder newQuery();
    UpdateExecBuilder newUpdate();
}

The main changes in QueryExec are as follows:

    public static QueryExecBuilder dataset(DatasetGraph dataset) {
        // Consult the registry to obtain an adapter implementation for the supplied dataset type.
        return SparqlAdapterRegistry.adapt(dataset).newQuery();
    }

    public static QueryExecDatasetBuilder newBuilder() {
        // We don't know the dataset yet, so adapter selection needs to be deferred until build().
        return QueryExecDatasetBuilderDeferred.create();
    }

Deferred Builders

The subsequent change is the introduction of a QueryExecDatasetBuilderDeferred, which chooses the right adapter during build. Conventionally, it will obtain the SparqlAdapter for the default query engine, obtain its QueryExecBuilder and transfer its own settings to it. The change for UpdateExec is likewise.

Major changes - For most users these should be source code compatible but they may not be byte code compatible:

• QueryExecBuilderDataset is now an interface. The original implementation is QueryExecBuilderDatasetImpl. The new one is QueryExecDatasetBuilderDeferred.
• QueryExecHTTP is now an interface. The original implementation is QueryExecHTTPImpl. The new one is QueryExecHTTPWrapper which can apply execution transformtions.

Exec Transformation

• QueryExecBuilder now features a transformExec(Function<QueryExec, QueryExec> qeTransform) method. This allows for post-processing the QueryExec being built without having to change the builder type. One way to add execution tracking via builders with preconfigured transforms. Alternatively, the builder itself could (in addition) include logic that consults the context for any post processing to apply to QueryExecs.
• UpdateExecBuilder likewise.

Are you interested in contributing a solution yourself?

Yes

[afs]

I'm having difficulty reviewing the PR because it is large, no fault of the issue and PR decscription.

I thought that execution tracking was now built-in now.

I would have expected that RDFLink would have different implementations which would mean that QueryExecDataset itself does not change. So obviously I'm not understand the design!

Could you give some examples of potential implementations/usages of SparqlAdapter including for the local case please?

[afs]

public interface SparqlAdapterProvider {
    SparqlAdapter adapt(DatasetGraph dsg);
    // Perhaps rename to "createAdapter" to avoid confusion with "adapt" methods in presentation layer classes.
}

It does feel like it is not "adapting" but "creating" - so create or createAdapter (as it is not a static to import, createSparqlAdapter would be unnecessary replication).