Maestro v0.2.0 Maestro.Store.InMemory View Source

Agent-based implementation of the event/snapshot storage mechanism

Link to this section Summary

Functions

Returns a specification to start this module under a supervisor

If any transactional projections are present, this function is an extension of commit_events that within the same transaction applies all projections to the store as well. Otherwise, this function dispatches to commit_events

Events are validated according to the Event.changeset/1 function. If successful, events are committed transactionally. In the event of a conflict on sequence number, the storage mechanism should indicate that the command could be retried by returning {:error, :retry_command}. The Aggregate’s command lifecycle will see the conflict and update the aggregate’s state before attempting to evaluate the command again. This allows for making stricter evaluation rules for commands. If the events could not be committed for any other reason, the storage mechanism should raise an appropriate exception

Snapshots are committed iff the proposed version is newer than the version already stored. This allows disconnected nodes to optimistically write their snapshots and still have a single version stored without conflicts

Events are retrieved by aggregate_id and with at least a minimum sequence number, seq. They should be ordered by sequence number to ensure that aggregates always process events in the same order

Snapshots can also be retrieved by aggregate_id and with at least a minimum sequence number, seq

Link to this section Functions

Returns a specification to start this module under a supervisor.

See Supervisor.

Link to this function commit_all(events, projections) View Source

If any transactional projections are present, this function is an extension of commit_events that within the same transaction applies all projections to the store as well. Otherwise, this function dispatches to commit_events.

Callback implementation for Maestro.Store.Adapter.commit_all/2.

Events are validated according to the Event.changeset/1 function. If successful, events are committed transactionally. In the event of a conflict on sequence number, the storage mechanism should indicate that the command could be retried by returning {:error, :retry_command}. The Aggregate’s command lifecycle will see the conflict and update the aggregate’s state before attempting to evaluate the command again. This allows for making stricter evaluation rules for commands. If the events could not be committed for any other reason, the storage mechanism should raise an appropriate exception.

Callback implementation for Maestro.Store.Adapter.commit_events/1.

Link to this function commit_snapshot(snapshot) View Source

Snapshots are committed iff the proposed version is newer than the version already stored. This allows disconnected nodes to optimistically write their snapshots and still have a single version stored without conflicts.

Callback implementation for Maestro.Store.Adapter.commit_snapshot/1.

Link to this function get_events(id, min_seq, map) View Source

Events are retrieved by aggregate_id and with at least a minimum sequence number, seq. They should be ordered by sequence number to ensure that aggregates always process events in the same order.

Additional option(s):

  • :max_sequence (integer): a hard upper limit on the sequence number. This is useful when attempting to recreate a past state of an aggregate.

Callback implementation for Maestro.Store.Adapter.get_events/3.

Link to this function get_snapshot(id, min_seq, map) View Source

Snapshots can also be retrieved by aggregate_id and with at least a minimum sequence number, seq.

Additional option(s):

  • :max_sequence (integer): a hard upper limit on the sequence number. This is useful when attempting to recreate a past state of an aggregate.

Callback implementation for Maestro.Store.Adapter.get_snapshot/3.

Link to this function in_range?(map, min, max) View Source