R2dbcReadJournal

Same type of query as EventsByPersistenceIdQuery#eventsByPersistenceId but the event stream is completed immediately when it reaches the end of the "result set". Events that are stored after the query is completed are not included in the event stream.

Same as CurrentEventsByPersistenceIdTypedQuery but with the purpose to use snapshot as starting point and thereby reducing number of events that have to be loaded.

Same type of query as EventsByPersistenceIdTypedQuery#eventsByPersistenceIdTyped but the event stream is completed immediately when it reaches the end of the "result set". Events that are stored after the query is completed are not included in the event stream.

This is a new version of the akka.persistence.query.javadsl.EventsByPersistenceIdQuery#currentEventsByPersistenceId using a new envelope type akka.persistence.query.typed.EventEnvelope.

Same type of query as EventsBySliceQuery.eventsBySlices but the event stream is completed immediately when it reaches the end of the "result set". Depending on journal implementation, this may mean all events up to when the query is started, or it may include events that are persisted while the query is still streaming results. For eventually consistent stores, it may only include all events up to some point before the query is started.

Same as currentEventsBySlices but with the purpose to use snapshots as starting points and thereby reducing number of events that have to be loaded. This can be useful if the consumer start from zero without any previously processed offset or if it has been disconnected for a long while and its offset is far behind.

First it loads all snapshots with timestamps greater than or equal to the offset timestamp. There is at most one snapshot per persistenceId. The snapshots are transformed to events with the given transformSnapshot function.

After emitting the snapshot events the ordinary events with sequence numbers after the snapshots are emitted.

To use currentEventsBySlicesStartingFromSnapshots you must enable configuration akka.persistence.r2dbc.query.start-from-snapshot.enabled and follow instructions in migration guide https://doc.akka.io/docs/akka-persistence-r2dbc/current/migration-guide.html#eventsBySlicesStartingFromSnapshots

Same type of query as PersistenceIdsQuery#persistenceIds but the stream is completed immediately when it reaches the end of the "result set". Persistent actors that are created after the query is completed are not included in the stream.

Get the current persistence ids.

Not all plugins may support in database paging, and may simply use drop/take Akka streams operators to manipulate the result set according to the paging parameters.

Get the current persistence ids.

Note: to reuse existing index, the actual query filters entity types based on persistence_id column and sql LIKE operator. Hence the persistenceId must start with an entity type followed by default separator ("|") from akka.persistence.typed.PersistenceId.

Query events for a specific PersistentActor identified by persistenceId.

You can retrieve a subset of all events by specifying fromSequenceNr and toSequenceNr or use 0L and Long.MAX_VALUE respectively to retrieve all events. The query will return all the events inclusive of the fromSequenceNr and toSequenceNr values.

The returned event stream should be ordered by sequence number.

The stream is not completed when it reaches the end of the currently stored events, but it continues to push new events when new events are persisted. Corresponding query that is completed when it reaches the end of the currently stored events is provided by CurrentEventsByPersistenceIdQuery#currentEventsByPersistenceId.

Same as EventsByPersistenceIdTypedQuery but with the purpose to use snapshot as starting point and thereby reducing number of events that have to be loaded.

Query events for a specific PersistentActor identified by persistenceId.

You can retrieve a subset of all events by specifying fromSequenceNr and toSequenceNr or use 0L and Long.MaxValue respectively to retrieve all events. The query will return all the events inclusive of the fromSequenceNr and toSequenceNr values.

The returned event stream should be ordered by sequence number.

The stream is not completed when it reaches the end of the currently stored events, but it continues to push new events when new events are persisted. Corresponding query that is completed when it reaches the end of the currently stored events is provided by CurrentEventsByPersistenceIdTypedQuery#currentEventsByPersistenceIdTyped.

This is a new version of the akka.persistence.query.javadsl.CurrentEventsByPersistenceIdQuery#currentEventsByPersistenceId using a new envelope type akka.persistence.query.typed.EventEnvelope.

Query events for given slices. A slice is deterministically defined based on the persistence id. The purpose is to evenly distribute all persistence ids over the slices.

The consumer can keep track of its current position in the event stream by storing the offset and restart the query from a given offset after a crash/restart.

The supported offset is akka.persistence.query.TimestampOffset and Offset.noOffset.

The timestamp is based on the database CURRENT_TIMESTAMP when the event was stored. CURRENT_TIMESTAMP is the time when the transaction started, not when it was committed. This means that a "later" event may be visible first and when retrieving events after the previously seen timestamp we may miss some events. In distributed SQL databases there can also be clock skews for the database timestamps. For that reason it will perform additional backtracking queries to catch missed events. Events from backtracking will typically be duplicates of previously emitted events. It's the responsibility of the consumer to filter duplicates and make sure that events are processed in exact sequence number order for each persistence id. Such deduplication is provided by the R2DBC Projection.

Events emitted by the backtracking don't contain the event payload (EventBySliceEnvelope.event is None) and the consumer can load the full EventBySliceEnvelope with R2dbcReadJournal.loadEnvelope.

The events will be emitted in the timestamp order with the caveat of duplicate events as described above. Events with the same timestamp are ordered by sequence number.

The stream is not completed when it reaches the end of the currently stored events, but it continues to push new events when new events are persisted. Corresponding query that is completed when it reaches the end of the currently stored events is provided by R2dbcReadJournal.currentEventsBySlices.

Same as eventsBySlices but with the purpose to use snapshots as starting points and thereby reducing number of events that have to be loaded. This can be useful if the consumer start from zero without any previously processed offset or if it has been disconnected for a long while and its offset is far behind.

First it loads all snapshots with timestamps greater than or equal to the offset timestamp. There is at most one snapshot per persistenceId. The snapshots are transformed to events with the given transformSnapshot function.

After emitting the snapshot events the ordinary events with sequence numbers after the snapshots are emitted.

To use eventsBySlicesStartingFromSnapshots you must enable configuration akka.persistence.r2dbc.query.start-from-snapshot.enabled and follow instructions in migration guide https://doc.akka.io/docs/akka-persistence-r2dbc/current/migration-guide.html#eventsBySlicesStartingFromSnapshots

Load a single event on demand. The CompletionStage is completed with a NoSuchElementException if the event for the given persistenceId and sequenceNr doesn't exist.