Execute a task within a repository transaction.
The task receives a per-call RepositoryClient bound to a transaction; updates and graph store writes
issued through it are applied within the transaction in order. If the task completes, the transaction commits; if
it throws or rejects, the transaction rolls back and the error propagates to the caller as a promise rejection.
Concurrent top-level execute calls run in independent transactions and never share state.
Every implementation must provide execute, but its guarantees are backend-dependent. A backend with native
transactions brackets the task for atomic commit and rollback. A backend without one supplies a degenerate
implementation: the task runs directly against this same Repository, with no atomicity and no
rollback. Either way, each implementation declares the isolation level it provides in its own factory
documentation.
execute is not re-entrant: while a task is running, it MUST NOT start another transaction by calling
execute again on the same repository. Transactions do not nest, so all operations that must commit together
have to run within a single execute call.
The task MUST NOT retain or use the RepositoryClient it receives after execute settles:
implementations may back it with transaction-scoped state (buffered mutations, a bound backend scope) that is
flushed or discarded on completion, so any later call has undefined behaviour.
Return type of the task
Async or sync function performing SPARQL operations on the per-call RepositoryClient
A promise resolving to the value returned by task; rejects with a
Problem if a transaction, network, storage, or other processing error occurs
Release resources held by this repository.
Frees underlying resources such as database connections or file handles. Calling close on an
already-closed repository has no effect.
Every implementation must provide close, but it is degenerate where there is nothing to release: a backend
that holds no resources implements it as a resolved no-op.
Callers MUST NOT use the repository after close settles: ask, select, construct, update, merge,
store and execute all have undefined behaviour once the underlying resources are released.
A promise resolving when all resources have been released; rejects with a Problem if a clean-up error occurs
Execute an ASK query.
A promise resolving to the boolean query result
Execute a CONSTRUCT query.
A promise resolving to the constructed RDF triples
Execute a SPARQL UPDATE operation.
A dataset is admitted only for updates declaring none of their own: SPARQL 1.1 Protocol forbids combining it
with USING, USING NAMED or WITH clauses, and the backend rejects such a request with its own error.
Merge triples into a graph.
Adds triples to the graph content, keeping the statements already there. Blank nodes in triples are kept
apart from those already in the store, as in an INSERT DATA update, so they never correlate with existing
nodes. Merging an empty array leaves the store unchanged, creating no named graph either.
The RDF triples to add
Optionalgraph: stringThe IRI of the target named graph, created if missing; when omitted, the default graph
Store triples as the content of a graph.
Replaces the graph content with triples, discarding the statements already there. Blank nodes in triples are
kept apart from those already in the store, as in merge. Storing an empty array
leaves the graph empty, while the other graphs of the store are never affected.
The RDF triples making up the new graph content
Optionalgraph: stringThe IRI of the target named graph, created if missing; when omitted, the default graph
SPARQL repository.
The interface connector packages implement to expose a concrete SPARQL backend. Extends the RepositoryClient query and update surface with transactional execute and lifecycle close.
execute provides best-effort transaction isolation: snapshot isolation where the backend supports it, degrading to the maximum level the storage achieves, down to none.
Each implementation must declare its supported isolation level in its factory documentation.
See