Splits the storage surface across two interfaces: StoreClient carries the CRUD and data-loading methods
that read and write linked-data resources described as Resource states and Template retrieval
templates from the @metreeca/qest data-modelling library, validated against
shapes defined using the @metreeca/blue validation
library; Store extends it with management facilities (mutation events, transactional execution, lifecycle).
Connectors compose the two — typically via createManagingStore —
into a single store exposing both surfaces through one object.
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 matching a validated retrieval template
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 an atomic unit of work; see
Store for isolation semantics.
Mutation Events
observe registers a StoreObserver for resource mutations, optionally filtered
by resource identifiers and their descendants.
Lifecycle
Every store exposes a close method that releases underlying resources
(database connections, file handles, observer subscriptions). Implementations with no resources to release
MAY return a resolved no-op.
Shape Validation
Resource data is automatically validated against the supplied shape:
The Transaction Design companion document covers the design rationale for transaction semantics,
including cross-backend isolation levels and concurrency models.
Model-driven storage API.
Splits the storage surface across two interfaces: StoreClient carries the CRUD and data-loading methods that read and write linked-data resources described as Resource states and Template retrieval templates from the @metreeca/qest data-modelling library, validated against shapes defined using the @metreeca/blue validation library; Store extends it with management facilities (mutation events, transactional execution, lifecycle). Connectors compose the two — typically via createManagingStore — into a single store exposing both surfaces through one object.
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 an atomic unit of work; see Store for isolation semantics.
Mutation Events
observe registers a StoreObserver for resource mutations, optionally filtered by resource identifiers and their descendants.
Lifecycle
Every store exposes a close method that releases underlying resources (database connections, file handles, observer subscriptions). Implementations with no resources to release MAY return a resolved no-op.
Shape Validation
Resource data is automatically validated against the supplied shape:
modelis validated for lookupstateis validated for create, update, and insertValidation 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— malformedentry(not an absolute IRI, contains?or#) or astatecarrying aniddiffering fromentrymodelorstatefails validate against the shapeCallers should
awaitandtry/catch(or chain.catch) at the call site; the rejection type discriminates logic errors 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.