[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [rdf4j-dev] New Memory Store - Planning
|
> On 19 Jul 2017, at 17:53, Håvard Ottestad <hmottestad@xxxxxxxxx> wrote:
>
> Could wrap it in locks and set the highest transaction level to “none”. Make .rollback() throw an unsupported operation.
That sounds like a possible approach, but I would stil prefer James’ suggestion to look at implementing a Model class and/or a “SPARQL on Models” utility instead.
Apart from anything else, something that tries to lock down concurrent access and doesn’t support transaction in my view doesn’t really fit with the design intent of the SAIL API. Moreover I feel that offering two different MemoryStore implementations as part of RDF4J will just be confusing to potential users.
> It would just be much nicer if there, in general, was one api for accessing graph data in rdf4j instead of the two that there are today.
They serve different purposes. SAIL (and, by implication, Repository) is for accessing persisted data in a scalable manner, multi-threaded manner. The SAIL API itself is designed to be a minimal API that encapsulates the basic functionality common to all such stores, and to describe a contract that all implementations must adhere to (e.g. supporting multithreaded access via connections). The Repository API is a usability layer on top of that.
The Model API is intended for quick in-memory manipulation of data, without bothering with transactions, open/closing connections, etc.
My gut feeling is still that your use case more closely fits with the design intent of the Model API.
> Layering the api, depending on what the underlying datastore supported would be much nicer. Eg. if the underlying datastore didn’t support transactions, then it’s connection wouldn’t have the begin() or commit() methods (using generics).
The point of SAIL is to be able to abstract away from the specific datastore’s capabilities, and to allow drop-in replacement of one datastore for another as much as possible. This is why the transaction isolation level is configurable - different stores support different levels. If you wish to have a database that doesn’t support transactions at all, you can implement it as you indicated above: only support the NONE level.
To be frank: in my opinion datastores that support no transactions at all have little usefulness in practice. You’d need to very carefully manage multithreaded access yourself, or make sure you only allow single-threaded access, which would severely limit the scalability of the whole application.
> Which came first, model or sail?
Well both APIs have evolved quite a bit over the years of course, but SAIL was definitely first. Sesame was originally conceived as an abstraction layer + query engine over a relational database.
Cheers,
Jeen
