evoq_lineage (evoq v1.20.0)

View Source

Lineage capability — the EIP correlation/causation identifiers as a first-class, intent-revealing API for evoq applications.

These are canonical Enterprise Integration Patterns (Hohpe and Woolf, 2004): every event carries a correlation_id (shared across one conversation, copied forward) and a causation_id (the id of the message that directly caused it). evoq sets them automatically on dispatch (see evoq_aggregate); this module is where consumers READ them and QUERY by them without hand-rolling the convention.

Layering

The reckon event store is generic and polyglot: it stores the ids as reserved metadata keys (causation_id / correlation_id / conversation_id, see reckon_shared.proto) and offers exactly one cross-cutting operation, read_by_metadata(Key, Value). It deliberately has NO server-side get_effects / get_causes / causation-graph verb — lineage assembly is a read-model concern (the same stance EventStoreDB takes with its $by_correlation_id projection).

This module is the BEAM/evoq layer that turns that generic primitive into the named operations the patterns describe. get_effects/2 and friends are thin wrappers over read_by_metadata with the blessed keys. Walking a multi-hop causation chain or building a graph is composed by the application on top of these, not done here and never in the store.

Summary

Functions

The id of the message that directly caused this event, or undefined. Tolerant of atom keys (events freshly produced in-process) and binary keys (events round-tripped through JSON storage).

The (usually domain-specific) conversation id tying multiple correlations to one conceptual operation, or undefined. Optional; only present when an application sets it.

The conversation id shared by every event in this chain, or undefined.

Every event tied to the conversation ConvId (i.e. events whose conversation_id equals it). Requires the application to set, and the store to index, the conversation_id key.

Every event in the conversation CorrId (i.e. events whose correlation_id equals it).

Events DIRECTLY caused by the message MessageId (i.e. events whose causation_id equals it). One hop — compose repeatedly for a chain.

Functions

causation_id(Meta)

-spec causation_id(map()) -> binary() | undefined.

The id of the message that directly caused this event, or undefined. Tolerant of atom keys (events freshly produced in-process) and binary keys (events round-tripped through JSON storage).

causation_key()

-spec causation_key() -> binary().

conversation_id(Meta)

-spec conversation_id(map()) -> binary() | undefined.

The (usually domain-specific) conversation id tying multiple correlations to one conceptual operation, or undefined. Optional; only present when an application sets it.

conversation_key()

-spec conversation_key() -> binary().

correlation_id(Meta)

-spec correlation_id(map()) -> binary() | undefined.

The conversation id shared by every event in this chain, or undefined.

correlation_key()

-spec correlation_key() -> binary().

get_conversation(StoreId, ConvId)

-spec get_conversation(atom(), binary()) -> {ok, [map()]} | {error, term()}.

Every event tied to the conversation ConvId (i.e. events whose conversation_id equals it). Requires the application to set, and the store to index, the conversation_id key.

get_correlated(StoreId, CorrId)

-spec get_correlated(atom(), binary()) -> {ok, [map()]} | {error, term()}.

Every event in the conversation CorrId (i.e. events whose correlation_id equals it).

get_effects(StoreId, MessageId)

-spec get_effects(atom(), binary()) -> {ok, [map()]} | {error, term()}.

Events DIRECTLY caused by the message MessageId (i.e. events whose causation_id equals it). One hop — compose repeatedly for a chain.