Model-driven resource store.
Model-driven resource CRUD operations.
Store mutation observer.
Store retrieval scope.
Store lookup request.
Store creation request.
Store update request.
Store deletion request.
Cross-backend transaction isolation semantics for Store
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.