Publishes the result of a continuous mapping.
The records of the mapping are published, the records listed in the result are deleted, and the high level FDO record of the mapping is created or updated.
Publishes all the records of a graph, without a mapping.
Publishes a single record, without a mapping.
Resolves a record by its PID, or returns undefined if no record with
that PID exists.
Staticreset
An in-memory backend for local testing, acting as a stand-in for a PID service and as the FDO flavor of the local testing setup. Implements both ContinuousPublishAdapter and ResolveAdapter.
The backend is not bound to a single mapping: the mapping is determined by the mapping result that is published, so one backend instance can publish and resolve any number of mappings.
Records can be published in three ways:
A record that is published without a PID is always published as a new record: it receives a fresh PID, even if a record with the same local ID was published before. A record that is published with a PID is upserted: the record is created under that PID, or an existing record with that PID is overwritten.
A continuous mapping decides which records are new and which ones already exist: the mapping result separates the records to create (no PID yet) from the records to update (with the PID they were published with in an earlier run) and the records to delete (with their PIDs). Running the same mapping against the same data therefore leaves the store unchanged, while every publication without a mapping grows the store.
The records are referenced by their local ID until they are published, just like a client that passes a placeholder PID to a PID service. The backend assigns the PIDs of all the records first and then fixes up the references: a reference to a record of the published set is expressed in terms of the PID the record was published with. Only the attributes that hold references are fixed up, so a mapping is free to store a local ID in any other attribute.
Every published record keeps its own local ID in the
0.SIMPLE/LOCAL_IDattribute. It is the only local ID that appears in a published record: it identifies the record for the mapping that published it.This attribute is a simplification of the testing backend, not a rule of the FDO model: every publish and resolve adapter has to implement its own mechanism for persisting local IDs, and it is free to choose one - record attributes, system metadata that is not part of the record, or even the PID itself. Nothing requires a local ID to be visible in the attributes of a record. The adapters only have to restore the local ID a record was published with when they resolve it, so references expressed in terms of local IDs can be resolved again.
As the flavor of this setup, the backend adds the high level FDO record of a mapping: it is a record with the PID of the mapping that references, bidirectionally, all the records that are part of the mapping. Every published record of the mapping therefore points back to the mapping it belongs to.
Published records can then be resolved again through resolveRecord and, grouped by mapping, through resolveMappingRecords.
All backend instances share one store, so records published for one mapping are resolvable through the backend instance of another mapping. Use resetStore to clear the store, e.g. between tests.