Server URL, repository identifier and the operation settings applied to every exchange
Readonlyserver: stringRDF4J Server base URL, for example http://localhost:8080/rdf4j-server
Readonlyrepository: stringRepository identifier within the RDF4J Server instance
Optional Readonlyinfer?: booleanWhether operations take inferred statements into account; when omitted, RDF4J includes them
wherever the repository computes them, so set it to false to restrict operations to explicit statements
Optional Readonlytimeout?: numberMaximum execution time of each operation, as a positive integer number of seconds; when omitted, operations run under the execution limit configured on the server, if any
Optional Readonlyfetch?: (input: RequestInfo | URL, init?: RequestInit) => Promise<Response>Custom fetch implementation used for every HTTP exchange, enabling header, auth, and
exchange customisation; defaults to the global fetch
A Repository instance
Creates a Repository backed by an RDF4J REST API endpoint.
Brackets every execute task in a server-managed RDF4J transaction, committed when the task completes and rolled back if it throws or any transactional operation fails.
Operations issued outside an enclosing
executetask are dispatched to the canonical SPARQL 1.1 Protocol endpoints (/repositories/{id}for query,/repositories/{id}/statementsfor update) by delegating to a createHTTPRepository instance, so a one-offask/updatedoes not pay the start-and-commit roundtrip cost. A Dataset is honoured both inside and outsideexecutetasks, as the same protocol parameters.merge and store upload their triples as N-Triples without parsing them as SPARQL text: outside
executetasks to the Graph Store Protocol service of the repository (/repositories/{id}/rdf-graphs/service), within them as transactionADDoperations, which astoreprecedes with aDROP SILENTupdate clearing the target graph. The default graph is the RDF4J null context.Transaction Isolation — Determined by the target RDF4J repository.
Error handling — every HTTP exchange is funnelled through createFetch, so:
status: 0statusTextasdetail, and the parsed body (RFC 7807 JSON, plain text, or omitted) asreportask/selectresponse rejects with a synthesised Problem carrying the response status and a parse-failuredetailconstructresponse whoseContent-Typeis not N-Triples rejects with a synthesised ProblemLocationheader on the start-transaction response rejects with a synthesised ProblemSyntaxErrorfor ill-formed N-Triples, or aRangeErrorfor a term component either syntax admits but the RDF data model rejects (a relative IRI, a lexical form holding an isolated surrogate, a non-conforming language tag), as well as for an unexpected SPARQL Results JSON termRollback is best-effort: a network or 5xx failure on rollback is swallowed, so the original task error propagates.
RDF4J Server does not apply
timeoutto updates issued within an execute task, so they always run to completion. Aborting the exchange through a customfetchdoes not stop them either: the update keeps running on the server, and the rollback waits for it to finish. Updates issued outsideexecutehonourtimeout, so an update that needs a time bound has to run there, giving up transactional atomicity.