Aklakan commented on code in PR #3511: URL: https://github.com/apache/jena/pull/3511#discussion_r2573142833
########## jena-arq/src/main/java/org/apache/jena/sparql/adapter/SparqlAdapter.java: ########## @@ -0,0 +1,27 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.jena.sparql.adapter; + +import org.apache.jena.sparql.exec.QueryExecBuilder; +import org.apache.jena.sparql.exec.UpdateExecBuilder; + +public interface SparqlAdapter { + QueryExecBuilder newQuery(); Review Comment: The basic idea of this proposal is to introduce SparqlAdapter as the one place in ARQ where eventually all the sparql level machinery over a DatasetGraph would go. Currently, this comprises the SPARQL subset covered by query and update exec builders. Streaming updates (UpdateExecSteaming) and GSP would require additional methods on SparqlAdapter. Conceptually, for a specific dataset implementation, there would be one specific `SparqlAdapter` instance - possibly dynamically assembled by a `SparqlAdapterProvider`. However, I think "real" custom implementations should build upon RDFLink - so the only ARQ-level adapter that needs to exist (besides that for the ARQ engine) is the bridge to RDFLink, which is based on `DatasetGraphOverRDFLink` and `SparqlAdapterProviderForDatasetGraphOverRDFLink.java` (registered within `jena-rdfconnection`) In the example above, `DatasetGraphOverRDFLink` is handled by an `SparqlAdapterProvider`. Using custom wrappers with DatasetGraphs (without registering custom providers) will fall back to the default ARQ engine provider `SparqlAdapterProviderMain`. An alternative design for `SparqlAdapter` is to keep `QueryExecBuilder`, `UpdateExecBuilder` and `GSP` in separate registries: `QueryExecBuilder.adapt(dsg)` would go to a `QueryExecBuilderRegistry` backed by a list of `QueryExecBuilderProviders` and the first match creates the final `QueryExecBuilder`. Same for update. So I think collecting this related functionality in a single `SparqlAdapter` system might be nicer. -- 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]
