Type Members

1.  trait AggregateEvent[E <: AggregateEvent[E]] extends AnyRef

   The base type of PersistentEntity events may implement this interface to make the events available for read-side processing.

2.  final class AggregateEventShards[Event <: AggregateEvent[Event]] extends AggregateEventTagger[Event]

   The base type of PersistentEntity events may return one of these to make the events available for sharded read-side processing.

   The base type of PersistentEntity events may return one of these to make the events available for sharded read-side processing.

   The tag should be unique among the event types of the service.

   The numShards should be stable and never change.

   The class name can be used as tag, but note that it is needed to retain the original tag when the class name is changed because the tag is part of the store event data.

3.  final class AggregateEventTag[Event <: AggregateEvent[Event]] extends AggregateEventTagger[Event]

   The base type of PersistentEntity events may return one of these to make the events available for read-side processing.

   The base type of PersistentEntity events may return one of these to make the events available for read-side processing.

   The tag should be unique among the event types of the service.

   The class name can be used as tag, but note that it is needed to retain the original tag when the class name is changed because the tag is part of the store event data.

4.  sealed trait AggregateEventTagger[Event <: AggregateEvent[Event]] extends AnyRef

   Selects a tag for an event.

   Selects a tag for an event.

   Can either be a static tag, or a sharded tag generator.

5.  final case class CommandEnvelope(entityId: String, payload: Any) extends Product with Serializable

   Commands to PersistentEntity are wrapped in this envelope when sent via PersistentEntityRef (i.e.

   Commands to PersistentEntity are wrapped in this envelope when sent via PersistentEntityRef (i.e. Cluster Sharding).

   Users should normally not use this class, but it is public case for power users in case of integration with Cluster Sharding entities that are not implemented with PersistentEntity.

6.  final class EventStreamElement[+Event] extends AnyRef

   Envelope for events in the eventstream, provides additional data to the actual event

7.  trait PersistenceComponents extends ReadSidePersistenceComponents

   Persistence components (for compile-time injection).

8.  abstract class PersistentEntity extends AnyRef

   A PersistentEntity has a stable entity identifier, with which it can be accessed from anywhere in the cluster.

   A PersistentEntity has a stable entity identifier, with which it can be accessed from anywhere in the cluster. It is run by an actor and the state is persistent using event sourcing.

   initialState and behavior are abstract methods that your concrete subclass must implement. The behavior is defined as a set of actions given a state. The actions are functions to process incoming commands and persisted events.

   The PersistentEntity receives commands of type Command that can be validated before persisting state changes as events of type Event. The functions that process incoming commands are registered in the Actions using onCommand of the Actions.

   A command may also be read-only and only perform some side-effect, such as replying to the request. Such command handlers are registered using onReadOnlyCommand of the Actions. Replies are sent with the reply method of the context that is passed to the command handler function.

   A command handler returns a Persist directive that defines what event or events, if any, to persist. Use the thenPersist, thenPersistAll or done methods of the context that is passed to the command handler function to create the Persist directive.

   When an event has been persisted successfully the state of type State is updated by applying the event to the current state. The functions for updating the state are registered with the onEvent method of the Actions. The event handler returns the new state. The state must be immutable, so you return a new instance of the state. Current state is passed as parameter to the event handler. The same event handlers are also used when the entity is started up to recover its state from the stored events.

   After persisting an event, external side effects can be performed in the afterPersist function that can be defined when creating the Persist directive. A typical side effect is to reply to the request to confirm that it was performed successfully. Replies are sent with the reply method of the context that is passed to the command handler function.

   The command handlers may emit zero, one or many events. When many events are emitted, they are stored atomically and in the same order they were emitted. Only after persisting all the events external side effects will be performed.

   The event handlers are typically only updating the state, but they may also change the behavior of the entity in the sense that new functions for processing commands and events may be defined for a given state. This is useful when implementing finite state machine (FSM) like entities.

   When the entity is started the state is recovered by replaying stored events. To reduce this recovery time the entity may start the recovery from a snapshot of the state and then only replaying the events that were stored after the snapshot. Such snapshots are automatically saved after a configured number of persisted events.

9.  final class PersistentEntityRef[Command] extends NoSerializationVerificationNeeded

   Commands are sent to a PersistentEntity using a PersistentEntityRef.

   Commands are sent to a PersistentEntity using a PersistentEntityRef. It is retrieved with PersistentEntityRegistry#refFor.

10.  trait PersistentEntityRegistry extends AnyRef

    At system startup all PersistentEntity classes must be registered here with PersistentEntityRegistry#register.

    At system startup all PersistentEntity classes must be registered here with PersistentEntityRegistry#register.

    Later, com.lightbend.lagom.scaladsl.persistence.PersistentEntityRef can be retrieved with PersistentEntityRegistry#refFor. Commands are sent to a com.lightbend.lagom.scaladsl.persistence.PersistentEntity using a PersistentEntityRef.

11.  trait ReadSide extends AnyRef

    The Lagom read-side registry.

    The Lagom read-side registry.

    Handles the management of read-sides.

12.  trait ReadSidePersistenceComponents extends WriteSidePersistenceComponents with ProjectionComponents

    Read-side persistence components (for compile-time injection).

13.  abstract class ReadSideProcessor[Event <: AggregateEvent[Event]] extends AnyRef

    A read side processor.

    A read side processor.

    Read side processors consume events produced by com.lightbend.lagom.scaladsl.persistence.PersistentEntity instances, and update some read side data store that is optimized for queries.

    The events they consume must be tagged, and a read side is able to consume events of one or more tags. Events are usually tagged according to some supertype of event, for example, events may be tagged as Order events. They may also be tagged according to a hash of the ID of the entity associated with the event - this allows read side event handling to be sharded across many nodes. Tagging is done using com.lightbend.lagom.scaladsl.persistence.AggregateEventTag.

    Read side processors are responsible for tracking what events they have already seen. This is done using offsets, which are sequential values associated with each event. Note that end users typically will not need to handle offsets themselves, this will be provided by Lagom support specific to the read side datastore, and end users can just focus on handling the events themselves.

14.  trait WriteSidePersistenceComponents extends ClusterComponents

    Write-side persistence components (for compile-time injection).