Execute a task within a repository transaction.
The task receives a per-call RepositoryClient bound to a transaction; updates issued through it are
applied within the transaction in order. If the task completes successfully, the transaction commits. If the task
throws or rejects, the transaction rolls back and the error is propagated 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, 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.
The SPARQL ASK query
A promise resolving to true if the query pattern matches; false otherwise
Execute a CONSTRUCT query.
The SPARQL CONSTRUCT query
A promise resolving to the constructed RDF triples
Execute a SPARQL UPDATE operation.
The SPARQL UPDATE request
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