Module khepri_adv

Khepri database advanced API.

Description

Khepri database advanced API.

This module exposes variants of the functions in khepri which return more detailed return values for advanced use cases. Here are some examples of what can be achieved with this module:

Functions provided by khepri are implemented on top of this module and simplify the return value for the more common use cases.

Data Types

many_results()

many_results() = khepri_machine:common_ret()

Return value of a query or synchronous command targeting many tree nodes.

node_props_map()

node_props_map() = #{khepri_path:native_path() => khepri:node_props()}

Structure used to return a map of nodes and their associated properties, payload and child nodes.

single_result()

single_result() = khepri:ok(khepri:node_props() | #{}) | khepri:error()

Return value of a query or synchronous command targeting one specific tree node.

Function Index

get/1Returns the properties and payload of the tree node pointed to by the given path pattern.
get/2Returns the properties and payload of the tree node pointed to by the given path pattern.
get/3Returns the properties and payload of the tree node pointed to by the given path pattern.
get_many/1Returns properties and payloads of all the tree nodes matching the given path pattern.
get_many/2Returns properties and payloads of all the tree nodes matching the given path pattern.
get_many/3Returns properties and payloads of all the tree nodes matching the given path pattern.
put/2Sets the payload of the tree node pointed to by the given path pattern.
put/3Sets the payload of the tree node pointed to by the given path pattern.
put/4Sets the payload of the tree node pointed to by the given path pattern.
put_many/2Sets the payload of all the tree nodes matching the given path pattern.
put_many/3Sets the payload of all the tree nodes matching the given path pattern.
put_many/4Sets the payload of all the tree nodes matching the given path pattern.
create/2Creates a tree node with the given payload.
create/3Creates a tree node with the given payload.
create/4Creates a tree node with the given payload.
update/2Updates an existing tree node with the given payload.
update/3Updates an existing tree node with the given payload.
update/4Updates an existing tree node with the given payload.
compare_and_swap/3Updates an existing tree node with the given payload only if its data matches the given pattern.
compare_and_swap/4Updates an existing tree node with the given payload only if its data matches the given pattern.
compare_and_swap/5Updates an existing tree node with the given payload only if its data matches the given pattern.
delete/1Deletes the tree node pointed to by the given path pattern.
delete/2Deletes the tree node pointed to by the given path pattern.
delete/3Deletes the tree node pointed to by the given path pattern.
delete_many/1Deletes all tree nodes matching the given path pattern.
delete_many/2Deletes all tree nodes matching the given path pattern.
delete_many/3Deletes all tree nodes matching the given path pattern.
clear_payload/1Deletes the payload of the tree node pointed to by the given path pattern.
clear_payload/2Deletes the payload of the tree node pointed to by the given path pattern.
clear_payload/3Deletes the payload of the tree node pointed to by the given path pattern.
clear_many_payloads/1Deletes the payload of all tree nodes matching the given path pattern.
clear_many_payloads/2Deletes the payload of all tree nodes matching the given path pattern.
clear_many_payloads/3Deletes the payload of all tree nodes matching the given path pattern.

Function Details

get/1

get(PathPattern) -> Ret

Returns the properties and payload of the tree node pointed to by the given path pattern.

Calling this function is the same as calling get(StoreId, PathPattern) with the default store ID (see khepri_cluster:get_default_store_id/0).

See also: get/2, get/3.

get/2

get(StoreId, PathPattern) -> Ret

get(PathPattern, Options) -> Ret

Returns the properties and payload of the tree node pointed to by the given path pattern.

This function accepts the following two forms:

See also: get/3.

get/3

get(StoreId, PathPattern, Options) -> Ret

StoreId: the name of the Khepri store.
PathPattern: the path (or path pattern) to the tree node to get.
Options: query options.

returns: an {ok, NodeProps} tuple or an {error, Reason} tuple.

Returns the properties and payload of the tree node pointed to by the given path pattern.

The PathPattern can be provided as a native path pattern (a list of tree node names and conditions) or as a string. See khepri_path:from_string/1.

The PathPattern must target a specific tree node. In other words, updating many nodes with the same payload is denied. That fact is checked before the tree node is looked up: so if a condition in the path could potentially match several nodes, an exception is raised, even though only one tree node would match at the time. If you want to get multiple nodes at once, use get_many/3.

The returned {ok, NodeProps} tuple contains a map with the properties and payload (if any) of the targeted tree node. If the tree node is not found, {error, ?khepri_error(node_not_found, Info)} is returned.

Example: query a tree node which holds the atom value
%% Query the tree node at `/:foo/:bar'.
{ok, #{data := value,
       payload_version := 1}} = khepri_adv:get(StoreId, [foo, bar]).
Example: query an existing tree node with no payload
%% Query the tree node at `/:no_payload'.
{ok, #{payload_version := 1}} = khepri_adv:get(StoreId, [no_payload]).
Example: query a non-existent tree node
%% Query the tree node at `/:non_existent'.
{error, ?khepri_error(node_not_found, _)} = khepri_adv:get(
                                              StoreId, [non_existent]).

See also: get_many/3, khepri:get/3.

get_many/1

get_many(PathPattern) -> Ret

Returns properties and payloads of all the tree nodes matching the given path pattern.

Calling this function is the same as calling get_many(StoreId, PathPattern) with the default store ID (see khepri_cluster:get_default_store_id/0).

See also: get_many/2, get_many/3.

get_many/2

get_many(StoreId, PathPattern) -> Ret

get_many(PathPattern, Options) -> Ret

Returns properties and payloads of all the tree nodes matching the given path pattern.

This function accepts the following two forms:

See also: get_many/3.

get_many/3

get_many(StoreId, PathPattern, Options) -> Ret

StoreId: the name of the Khepri store.
PathPattern: the path (or path pattern) to the tree nodes to get.
Options: query options such as favor.

returns: an {ok, NodePropsMap} tuple or an {error, Reason} tuple.

Returns properties and payloads of all the tree nodes matching the given path pattern.

The PathPattern can be provided as a native path pattern (a list of tree node names and conditions) or as a string. See khepri_path:from_string/1.

The returned {ok, NodePropsMap} tuple contains a map where keys correspond to the path to a tree node matching the path pattern. Each key then points to a map containing the properties and payload (if any) of that matching tree node.

Example: query all nodes in the tree
%% Get all nodes in the tree. The tree is:
%% <root>
%% `-- foo
%%     `-- bar = value
{ok, #{[foo] :=
       #{payload_version := 1},
       [foo, bar] :=
       #{data := value,
         payload_version := 1}}} = khepri_adv:get_many(
                                     StoreId,
                                     [?KHEPRI_WILDCARD_STAR_STAR]).

See also: get/3, khepri:get_many/3.

put/2

put(PathPattern, Data) -> Ret

Sets the payload of the tree node pointed to by the given path pattern.

Calling this function is the same as calling put(StoreId, PathPattern, Data) with the default store ID (see khepri_cluster:get_default_store_id/0).

See also: put/3, put/4.

put/3

put(StoreId, PathPattern, Data) -> Ret

Sets the payload of the tree node pointed to by the given path pattern.

Calling this function is the same as calling put(StoreId, PathPattern, Data, #{}).

See also: put/4.

put/4

put(StoreId, PathPattern, Data, Options) -> Ret

StoreId: the name of the Khepri store.
PathPattern: the path (or path pattern) to the tree node to create or modify.
Data: the Erlang term or function to store, or a khepri_payload:payload() structure.
Options: command options.

returns: in the case of a synchronous call, an {ok, NodeProps} tuple or an {error, Reason} tuple; in the case of an asynchronous call, always ok (the actual return value may be sent by a message if a correlation ID was specified).

Sets the payload of the tree node pointed to by the given path pattern.

The PathPattern can be provided as a native path pattern (a list of tree node names and conditions) or as a string. See khepri_path:from_string/1.

The PathPattern must target a specific tree node. In other words, updating many nodes with the same payload is denied. That fact is checked before the tree node is looked up: so if a condition in the path could potentially match several nodes, an exception is raised, even though only one tree node would match at the time.

When using a simple path (i.e. without conditions), if the targeted tree node does not exist, it is created using the given payload. If the targeted tree node exists, it is updated with the given payload and its payload version is increased by one. Missing parent nodes are created on the way.

When using a path pattern, the behavior is the same. However if a condition in the path pattern is not met, an error is returned and the tree structure is not modified.

The returned {ok, NodeProps} tuple contains a map with the properties and payload (if any) of the targeted tree node: the payload was the one before the update, other properties like the payload version correspond to the updated node. If the targeted tree node didn't exist, NodeProps will be an empty map.

The payload must be one of the following form:

It is possible to wrap the payload in its internal structure explicitly using the khepri_payload module directly.

The Options map may specify command-level options; see khepri:command_options(), khepri:tree_options() and khepri:put_options().

When doing an asynchronous update, the handle_async_ret/1 function should be used to handle the message received from Ra.

The returned {ok, NodeProps} tuple contains a map with the properties and payload (if any) of the targeted tree node as they were before the put.

Example:
%% Insert a tree node at `/:foo/:bar', overwriting the previous value.
{ok, #{data := value,
       payload_version := 1}} = khepri_adv:put(
                                  StoreId, [foo, bar], new_value).

See also: compare_and_swap/5, create/4, update/4, khepri:put/4.

put_many/2

put_many(PathPattern, Data) -> Ret

Sets the payload of all the tree nodes matching the given path pattern.

Calling this function is the same as calling put_many(StoreId, PathPattern, Data) with the default store ID (see khepri_cluster:get_default_store_id/0).

See also: put_many/3, put_many/4.

put_many/3

put_many(StoreId, PathPattern, Data) -> Ret

Sets the payload of all the tree nodes matching the given path pattern.

Calling this function is the same as calling put_many(StoreId, PathPattern, Data, #{}).

See also: put_many/4.

put_many/4

put_many(StoreId, PathPattern, Data, Options) -> Ret

StoreId: the name of the Khepri store.
PathPattern: the path (or path pattern) to the tree node to create or modify.
Data: the Erlang term or function to store, or a khepri_payload:payload() structure.
Options: command options.

returns: in the case of a synchronous call, an {ok, NodePropsMap} tuple or an {error, Reason} tuple; in the case of an asynchronous call, always ok (the actual return value may be sent by a message if a correlation ID was specified).

Sets the payload of all the tree nodes matching the given path pattern.

The PathPattern can be provided as a native path pattern (a list of tree node names and conditions) or as a string. See khepri_path:from_string/1.

When using a simple path (i.e. without conditions), if the targeted tree node does not exist, it is created using the given payload. If the targeted tree node exists, it is updated with the given payload and its payload version is increased by one. Missing parent nodes are created on the way.

When using a path pattern, the behavior is the same. However if a condition in the path pattern is not met, an error is returned and the tree structure is not modified.

The returned {ok, NodePropsMap} tuple contains a map where keys correspond to the path to a tree node matching the path pattern. Each key then points to a map containing the properties and payload (if any) of the targeted tree node: the payload was the one before the update, other properties like the payload version correspond to the updated node.

The payload must be one of the following form:

It is possible to wrap the payload in its internal structure explicitly using the khepri_payload module directly.

The Options map may specify command-level options; see khepri:command_options(), khepri:tree_options() and khepri:put_options().

When doing an asynchronous update, the handle_async_ret/1 function should be used to handle the message received from Ra.

Example:
%% Set value of all tree nodes matching `/*/:bar', to `new_value'.
{ok, #{[foo, bar] :=
       #{data := value,
         payload_version := 1},
       [baz, bar] :=
       #{payload_version := 1}}} = khepri_adv:put_many(
                                     StoreId,
                                     [?KHEPRI_WILDCARD_STAR, bar],
                                     new_value).

See also: put/4, khepri:put_many/4.

create/2

create(PathPattern, Data) -> Ret

Creates a tree node with the given payload.

Calling this function is the same as calling create(StoreId, PathPattern, Data) with the default store ID (see khepri_cluster:get_default_store_id/0).

See also: create/3, create/4.

create/3

create(StoreId, PathPattern, Data) -> Ret

Creates a tree node with the given payload.

Calling this function is the same as calling create(StoreId, PathPattern, Data, #{}).

See also: create/4.

create/4

create(StoreId, PathPattern, Data, Options) -> Ret

StoreId: the name of the Khepri store.
PathPattern: the path (or path pattern) to the tree node to create.
Data: the Erlang term or function to store, or a khepri_payload:payload() structure.
Options: command options.

returns: in the case of a synchronous call, an {ok, NodeProps} tuple or an {error, Reason} tuple; in the case of an asynchronous call, always ok (the actual return value may be sent by a message if a correlation ID was specified).

Creates a tree node with the given payload.

The behavior is the same as put/4 except that if the tree node already exists, an {error, ?khepri_error(mismatching_node, Info)} tuple is returned.

Internally, the PathPattern is modified to include an #if_node_exists{exists = false} condition on its last component.

See also: put/4, update/4, khepri:create/4.

update/2

update(PathPattern, Data) -> Ret

Updates an existing tree node with the given payload.

Calling this function is the same as calling update(StoreId, PathPattern, Data) with the default store ID (see khepri_cluster:get_default_store_id/0).

See also: update/3, update/4.

update/3

update(StoreId, PathPattern, Data) -> Ret

Updates an existing tree node with the given payload.

Calling this function is the same as calling update(StoreId, PathPattern, Data, #{}).

See also: update/4.

update/4

update(StoreId, PathPattern, Data, Options) -> Ret

StoreId: the name of the Khepri store.
PathPattern: the path (or path pattern) to the tree node to modify.
Data: the Erlang term or function to store, or a khepri_payload:payload() structure.
Options: command options.

returns: in the case of a synchronous call, an {ok, NodeProps} tuple or an {error, Reason} tuple; in the case of an asynchronous call, always ok (the actual return value may be sent by a message if a correlation ID was specified).

Updates an existing tree node with the given payload.

The behavior is the same as put/4 except that if the tree node already exists, an {error, ?khepri_error(mismatching_node, Info)} tuple is returned.

Internally, the PathPattern is modified to include an #if_node_exists{exists = true} condition on its last component.

See also: create/4, put/4, khepri:update/4.

compare_and_swap/3

compare_and_swap(PathPattern, DataPattern, Data) -> Ret

Updates an existing tree node with the given payload only if its data matches the given pattern.

Calling this function is the same as calling compare_and_swap(StoreId, PathPattern, DataPattern, Data) with the default store ID (see khepri_cluster:get_default_store_id/0).

See also: compare_and_swap/4, compare_and_swap/5.

compare_and_swap/4

compare_and_swap(StoreId, PathPattern, DataPattern, Data) -> Ret

Updates an existing tree node with the given payload only if its data matches the given pattern.

Calling this function is the same as calling compare_and_swap(StoreId, PathPattern, DataPattern, Data, #{}).

See also: compare_and_swap/5.

compare_and_swap/5

compare_and_swap(StoreId, PathPattern, DataPattern, Data, Options) -> Ret

StoreId: the name of the Khepri store.
PathPattern: the path (or path pattern) to the tree node to modify.
Data: the Erlang term or function to store, or a khepri_payload:payload() structure.
Options: command options.

returns: in the case of a synchronous call, an {ok, NodeProps} tuple or an {error, Reason} tuple; in the case of an asynchronous call, always ok (the actual return value may be sent by a message if a correlation ID was specified).

Updates an existing tree node with the given payload only if its data matches the given pattern.

The behavior is the same as put/4 except that if the tree node already exists, an {error, ?khepri_error(mismatching_node, Info)} tuple is returned.

Internally, the PathPattern is modified to include an #if_data_matches{pattern = DataPattern} condition on its last component.

See also: put/4, khepri:compare_and_swap/5.

delete/1

delete(PathPattern) -> Ret

Deletes the tree node pointed to by the given path pattern.

Calling this function is the same as calling delete(StoreId, PathPattern) with the default store ID (see khepri_cluster:get_default_store_id/0).

See also: delete/2, delete/3.

delete/2

delete(StoreId, PathPattern) -> Ret

delete(PathPattern, Options) -> Ret

Deletes the tree node pointed to by the given path pattern.

This function accepts the following two forms:

See also: delete/3.

delete/3

delete(StoreId, PathPattern, Options) -> Ret

StoreId: the name of the Khepri store.
PathPattern: the path (or path pattern) to the nodes to delete.
Options: command options such as the command type.

returns: in the case of a synchronous call, an {ok, NodeProps} tuple or an {error, Reason} tuple; in the case of an asynchronous call, always ok (the actual return value may be sent by a message if a correlation ID was specified).

Deletes the tree node pointed to by the given path pattern.

The PathPattern can be provided as a native path pattern (a list of tree node names and conditions) or as a string. See khepri_path:from_string/1.

The PathPattern must target a specific tree node. In other words, updating many nodes with the same payload is denied. That fact is checked before the tree node is looked up: so if a condition in the path could potentially match several nodes, an exception is raised, even though only one tree node would match at the time. If you want to delete multiple nodes at once, use delete_many/3.

The returned {ok, NodeProps} tuple contains a map with the properties and payload (if any) of the targeted tree node as they were before the delete. If the targeted tree node didn't exist, NodeProps will be an empty map.

When doing an asynchronous update, the handle_async_ret/1 function should be used to handle the message received from Ra.

Example:
%% Delete the tree node at `/:foo/:bar'.
{ok, #{data := value,
       payload_version := 1}} = khepri_adv:delete(StoreId, [foo, bar]).

See also: delete_many/3, khepri:delete/3.

delete_many/1

delete_many(PathPattern) -> Ret

Deletes all tree nodes matching the given path pattern.

Calling this function is the same as calling delete_many(StoreId, PathPattern) with the default store ID (see khepri_cluster:get_default_store_id/0).

See also: delete_many/2, delete_many/3.

delete_many/2

delete_many(StoreId, PathPattern) -> Ret

delete_many(PathPattern, Options) -> Ret

Deletes all tree nodes matching the given path pattern.

This function accepts the following two forms:

See also: delete_many/3.

delete_many/3

delete_many(StoreId, PathPattern, Options) -> Ret

StoreId: the name of the Khepri store.
PathPattern: the path (or path pattern) to the nodes to delete.
Options: command options such as the command type.

returns: in the case of a synchronous call, an {ok, NodePropsMap} tuple or an {error, Reason} tuple; in the case of an asynchronous call, always ok (the actual return value may be sent by a message if a correlation ID was specified).

Deletes all tree nodes matching the given path pattern.

The PathPattern can be provided as a native path pattern (a list of tree node names and conditions) or as a string. See khepri_path:from_string/1.

The returned {ok, NodePropsMap} tuple contains a map where keys correspond to the path to a deleted tree node. Each key then points to a map containing the properties and payload (if any) of that deleted tree node as they were before the delete.

When doing an asynchronous update, the handle_async_ret/1 function should be used to handle the message received from Ra.

Example:
%% Delete the tree node at `/:foo/:bar'.
{ok, #{[foo, bar] := #{data := value,
                       payload_version := 1},
       [baz, bar] := #{payload_version := 1}}} = khepri_adv:delete_many(
                                                   StoreId, [foo, bar]).

See also: delete/3, khepri:delete/3.

clear_payload/1

clear_payload(PathPattern) -> Ret

Deletes the payload of the tree node pointed to by the given path pattern.

Calling this function is the same as calling clear_payload(StoreId, PathPattern) with the default store ID (see khepri_cluster:get_default_store_id/0).

See also: clear_payload/2, clear_payload/3.

clear_payload/2

clear_payload(StoreId, PathPattern) -> Ret

Deletes the payload of the tree node pointed to by the given path pattern.

Calling this function is the same as calling clear_payload(StoreId, PathPattern, #{}).

See also: clear_payload/3.

clear_payload/3

clear_payload(StoreId, PathPattern, Options) -> Ret

StoreId: the name of the Khepri store.
PathPattern: the path (or path pattern) to the tree node to modify.
Options: command options.

returns: in the case of a synchronous call, an {ok, NodeProps} tuple or an {error, Reason} tuple; in the case of an asynchronous call, always ok (the actual return value may be sent by a message if a correlation ID was specified).

Deletes the payload of the tree node pointed to by the given path pattern.

In other words, the payload is set to khepri_payload:no_payload(). Otherwise, the behavior is that of update/4.

See also: update/4, khepri:clear_payload/3.

clear_many_payloads/1

clear_many_payloads(PathPattern) -> Ret

Deletes the payload of all tree nodes matching the given path pattern.

Calling this function is the same as calling clear_many_payloads(StoreId, PathPattern) with the default store ID (see khepri_cluster:get_default_store_id/0).

See also: clear_many_payloads/2, clear_many_payloads/3.

clear_many_payloads/2

clear_many_payloads(StoreId, PathPattern) -> Ret

Deletes the payload of all tree nodes matching the given path pattern.

Calling this function is the same as calling clear_many_payloads(StoreId, PathPattern, #{}).

See also: clear_many_payloads/3.

clear_many_payloads/3

clear_many_payloads(StoreId, PathPattern, Options) -> Ret

StoreId: the name of the Khepri store.
PathPattern: the path (or path pattern) to the tree nodes to modify.
Options: command options.

returns: in the case of a synchronous call, an {ok, NodePropsMap} tuple or an {error, Reason} tuple; in the case of an asynchronous call, always ok (the actual return value may be sent by a message if a correlation ID was specified).

Deletes the payload of all tree nodes matching the given path pattern.

In other words, the payload is set to khepri_payload:no_payload(). Otherwise, the behavior is that of put/4.

See also: delete_many/3, put/4, khepri:clear_many_payloads/3.


Generated by EDoc