This project has moved. For the latest updates, please go here.

Connection strings for other stores

Coordinator
Jan 25, 2014 at 5:21 PM
Hi all,

I've been reviewing the recent discussions about EF and in particular thinking about the way(s) in which we currently specify the connection strings for connecting to other stores. I have a proposal for some changes which I would like to run by you all to get some extra eyes on it to make sure that I haven't missed anything out.

Principles

Before going into the details, I should say that the basic principles here (as I see them are)
  1. Don't repeat stuff that can be handled in DNR configuration. This is both to keep the connector code clean and also to avoid stuff breaking if DNR configuration is extended / changed.
  2. Keep it as simple as possible - there are a bunch of different options but it should be as easy as possible for a user/developer to match their particular situation to one (and ideally only one) of the options. That way we can write short templates / how-tos for the most common configuration scenarios.
  3. Provide a way to pass user credentials at runtime. This sort of conflicts with (1) because DNR configuration does have properties for this, but I imagine that there are all sorts of scenarios where people will not want to have credentials in a plain text RDF file. Making it part of the connection string means that it is possible to pass these through at runtime.

Configuration Scenarios

OK, so the two configuration scenarios I have come up with are as follows:
  1. One or more stores defined in the configuration file.
    type=dotNetRdf;configuration={file_path}
    NOTE: No store parameter, instead stores are accessed by using the store URI as the store name. Relative URIs are resolved against the base URI of the configuration). The resource that is resolved in the configuration graph must be a dnr:StorageProvider - if it is anything else, it is a runtime exception. If the StorageProvider does not support update, the created context will be a readonly context.
  2. A single DNR storage server.
    type=dotNetRdf;configuration={file_path};storageServer={uri}
    The {uri} is the URI of the storage server configuration resource. Relative URIs are resolved against the base URI of the configuration. Store operations are then managed through the storage server API.
  3. A generic SPARQL endpoint
    type=sparql;query={query_uri};update={update_uri}
    This is a convenience form that enables users to connect to a generic SPARQL endpoint without having to create a DNR configuration file. It could be useful for applications that want to connect to user-defined SPARQL endpoints at runtime. The update= can be ommitted to create a readonly context.
In either of the above, it is also possible to add user= and password= parameters to the connection string, these will add dnr:user and dnr:password properties automatically to the configuration resources (unless the resource already has them).

What about the old store=;storeName= connection strings?

They shall die :-) The configuration for a single store with a fixed storeName is just a degenerate form of (1) - it adds no real benefit.

It would be great to hear some thoughts on this, especially if there is some scenario that you think I've missed or made hard to achieve through these changes.

Cheers

Kal
Jan 27, 2014 at 9:54 PM
I like the principles/config scenarios, and it seems good to drop the old "store" params in favor of suggested approach. What i'm thinking is that the context should not depend on the configuration but on the objects that it uses (ISparqlUpdateProcessor, ISparqlQueryProcessor, etc) to perform his function. So another principle could be to allow an alternative for providing necessary dependencies through IOC(create DNR objects at runtime) along with configuration.
Coordinator
Jan 28, 2014 at 11:34 AM
I agree that passing in DNR objects at run-time has to be supported.

But when it is a configuration graph (whether it comes from the connection string or from constructor injection) in some cases it won't be possible to determine what sort of context was intended from the configuration (e.g. if the configuration graph contains a StorageServer and a StorageProvider) - then there would either have to be a run-time error or a default behaviour. Also I was tempted to drop the simple SPARQL query and update connection string format, but it seemed to me that this would be a useful one to be able to support without requiring the user to write a DNR configuration file - and it should also be supported through constructor injection.