Persists and retrieves linked data resources independently of the backend holding them. Resources are described by
shapes defined with the @metreeca/blue validation library.
They are read and written as Resource states, Template retrieval templates and Projection
queries, following the data and query models of the @metreeca/qest
data-modelling library.
A StoreClient defines the data operations a connector implements against its backend. A Store adds
mutation events, transactional execution and lifecycle management, and exposes both surfaces through one object.
Connectors typically obtain the management surface from createManagingStore.
StoreClient implementations are expected to fully support the query language
defined by @metreeca/qest, including property selection, linked
resource expansion, filtering, ordering, and pagination.
CRUD Operations
The StoreClient interface supports conditional resource operations for standard CRUD workflows:
lookup — Retrieve a resource, narrowed to a validated retrieval template
create — Add a resource from a validated state to a collection held by another resource
update — Replace a resource state with a validated state
delete — Delete a resource identified by a validated entry
Data Loading
For direct data loading, the following unconditional operations bypass existence checks:
insert — Unconditionally upsert a resource from a validated state
remove — Unconditionally remove a resource identified by a validated entry
Transactions
execute groups multiple operations into a single unit of work; see
Store for atomicity and isolation semantics.
Mutation Events
observe registers a StoreObserver for resource mutations, optionally filtered
by resource identifiers and their descendants.
Lifecycle
close releases the resources held by a store, such as database connections, file handles and
observer subscriptions.
Shape Validation
Request data is validated against the supplied shape before it reaches the backend:
state is validated for update and insert against the
supplied shape, and for create against the shape of the collected resources
Validation failures surface as a TraceError carrying the collected failure trace.
Error Channel
Every StoreClient method returns a Promise<…>; all errors are delivered as promise
rejections, regardless of origin:
RangeError — malformed entry (not an absolute IRI, contains ? or #), a state whose
id conflicts with entry (not nested under it on creation, differing from it otherwise), or a state member
filling an identifier slot that is not a single path segment
Problem — network, storage, or other processing failures
Errors are therefore handled at the call site, with await and try/catch or a chained .catch. The rejection
type tells logic errors apart from process errors.
Retrieving Resources
// single resource retrieval with explicit template
The Transaction Design companion document covers the design rationale for transaction semantics,
including cross-backend isolation levels and concurrency models.
Core model-driven storage API.
Persists and retrieves linked data resources independently of the backend holding them. Resources are described by shapes defined with the @metreeca/blue validation library. They are read and written as Resource states, Template retrieval templates and Projection queries, following the data and query models of the @metreeca/qest data-modelling library.
A StoreClient defines the data operations a connector implements against its backend. A Store adds mutation events, transactional execution and lifecycle management, and exposes both surfaces through one object. Connectors typically obtain the management surface from createManagingStore.
StoreClient implementations are expected to fully support the query language defined by @metreeca/qest, including property selection, linked resource expansion, filtering, ordering, and pagination.
CRUD Operations
The StoreClient interface supports conditional resource operations for standard CRUD workflows:
Data Loading
For direct data loading, the following unconditional operations bypass existence checks:
Transactions
execute groups multiple operations into a single unit of work; see Store for atomicity and isolation semantics.
Mutation Events
observe registers a StoreObserver for resource mutations, optionally filtered by resource identifiers and their descendants.
Lifecycle
close releases the resources held by a store, such as database connections, file handles and observer subscriptions.
Shape Validation
Request data is validated against the supplied shape before it reaches the backend:
modelis validated for lookup and createstateis validated for update and insert against the supplied shape, and for create against the shape of the collected resourcesValidation failures surface as a TraceError carrying the collected failure trace.
Error Channel
Every StoreClient method returns a
Promise<…>; all errors are delivered as promise rejections, regardless of origin:entry(not an absolute IRI, contains?or#), astatewhoseidconflicts withentry(not nested under it on creation, differing from it otherwise), or astatemember filling an identifier slot that is not a single path segmentmodelorstatefails validate against the shapeErrors are therefore handled at the call site, with
awaitandtry/catchor a chained.catch. The rejection type tells logic errors apart from process errors.Retrieving Resources
Creating and Updating Resources
Deleting Resources
Loading Data
Observing Mutations
Executing Transactions
The Transaction Design companion document covers the design rationale for transaction semantics, including cross-backend isolation levels and concurrency models.