Interface EventsBySliceQuery
-
- All Superinterfaces:
ReadJournal
- All Known Implementing Classes:
EventsBySliceFirehoseQuery
,PersistenceTestKitDurableStateStore
public interface EventsBySliceQuery extends ReadJournal
A plugin may optionally support this query by implementing this trait.EventsBySliceQuery
that is using a timestamp based offset should also implementEventTimestampQuery
andLoadEventQuery
.See also
EventsBySliceFirehoseQuery
.
-
-
Method Summary
All Methods Instance Methods Abstract Methods Modifier and Type Method Description <Event> Source<EventEnvelope<Event>,NotUsed>
eventsBySlices(java.lang.String entityType, int minSlice, int maxSlice, Offset offset)
Query events for given slices.int
sliceForPersistenceId(java.lang.String persistenceId)
java.util.List<Pair<java.lang.Integer,java.lang.Integer>>
sliceRanges(int numberOfRanges)
-
-
-
Method Detail
-
eventsBySlices
<Event> Source<EventEnvelope<Event>,NotUsed> eventsBySlices(java.lang.String entityType, int minSlice, int maxSlice, Offset offset)
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 givenoffset
after a crash/restart.The exact meaning of the
offset
depends on the journal and must be documented by the read journal plugin. It may be a sequential id number that uniquely identifies the position of each event within the event stream. Distributed data stores cannot easily support those semantics and they may use a weaker meaning. For example it may be a timestamp (taken when the event was created or stored). Timestamps are not unique and not strictly ordered, since clocks on different machines may not be synchronized.In strongly consistent stores, where the
offset
is unique and strictly ordered, the stream should start from the next event after theoffset
. Otherwise, the read journal should ensure that between an invocation that returned an event with the givenoffset
, and this invocation, no events are missed. Depending on the journal implementation, this may mean that this invocation will return events that were already returned by the previous invocation, including the event with the passed inoffset
.The returned event stream should be ordered by
offset
if possible, but this can also be difficult to fulfill for a distributed data store. The order must be documented by the read journal plugin.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
CurrentEventsBySliceQuery.currentEventsBySlices
.
-
sliceForPersistenceId
int sliceForPersistenceId(java.lang.String persistenceId)
-
sliceRanges
java.util.List<Pair<java.lang.Integer,java.lang.Integer>> sliceRanges(int numberOfRanges)
-
-