View provides an in-memory partial mirror of the store, with lazy reads and delayed writes.
Views are like staging area in Git: they are temporary non-persistent areas (they disappear if the host crash), held in memory for efficiency, where reads are done lazily and writes are done only when needed on commit: if you modify a key twice, only the last change will be written to the store when you commit. Views also hold a list of operations, which are checked for conflicts on commits and are used to replay/rebase the view if needed. The most important feature of views is that they keep track of reads: i.e. you can have a conflict if a view reads a key which has been modified concurrently by someone else.
A view is a read-write temporary store, mirroring the main store.
include HRWHierarchical read-write stores are read-write stores using paths as keys. They are a very simplified abstraction of filesystems.
include RWupdate t k v replaces the contents of k by v in t. If k is not already defined in t, create a fresh binding. Raise Invalid_argument if k is the empty path.
compare_and_set t key ~test ~set sets key to set only if the current value of key is test and in that case returns true. If the current value of key is different, it returns false. None means that the value does not have to exist or is removed.
Note: The operation is guaranteed to be atomic.
Create an empty view. Empty views do not have associated backend configuration values, as they can perform in-memory operation, independently of any given backend.
val rebase : t -> into:t -> unit Merge.result Lwt.trebase x t i rebases the actions done on the view t x into the view i x. If a read operation doesn't return the same result, return Conflict. Only the view i is updated.
Same as rebase but raise Merge.Conflict in case of conflict.
of_path t p reads the view from a path p in the branch t. This is a cheap operation, all the real reads operation will be done on-demand when the view is used. If p does not exist in t, the the result is an empty view.
update_path t p v replaces the sub-tree under p in the branch t by the contents of the view v. See merge_path for more details.
val rebase_path : db -> key -> t -> unit Merge.result Lwt.trebase_path t p v rebases the view v on top of the contents of the sub-tree under p in the branch t. Rebasing means re-applying every action stored in v, including the reads. Return Merge.Conflict if one of the actions cannot apply cleanly. See merge_path for more details.
Same as rebase_path but raise Merge.Conflict in case of conflict.
val merge_path :
db ->
?max_depth:int ->
?n:int ->
key ->
t ->
unit Merge.result Lwt.tmerge_path t path v merges the view v with the contents of the sub-tree under p in the branch t. Merging means applying the merge function for map between the view's contents and t's sub-tree.
VIEW.update_path discards any pre-existing subtree.VIEW.rebase_path is operation based. It keeps track of read operations which can lead to conflicts. It replays the full operation history of the view on top of any pre-existing subtree.VIEW.merge_path is state based. It is an efficient 3-way merge operator between prefix trees, based on Merge.Map.merge.Same as merge_path but raises Merge.Conflict in case of conflicts.
module Action : sig ... endAction provides information about operations performed on a view.
Return the list of actions performed on this view since its creation.
make_head t task ~parents ~contents creates a new commit into the store where the branch t is stored and return its id (of type commit_id). The new commit has task as task and the given parents and contents. The actual parents of contents are not used.