Improved docs for some queries (#28033)
Made it clear whether offset/to/fromSequenceNr are inclusive or exclusive. Co-Authored-By: Helena Edelson <helena@users.noreply.github.com>
This commit is contained in:
parent
365af7ee2f
commit
43ec699b77
6 changed files with 28 additions and 6 deletions
|
|
@ -15,8 +15,11 @@ trait CurrentEventsByTagQuery extends ReadJournal {
|
|||
|
||||
/**
|
||||
* Same type of query as [[EventsByTagQuery#eventsByTag]] 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.
|
||||
* 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.
|
||||
*/
|
||||
def currentEventsByTag(tag: String, offset: Offset): Source[EventEnvelope, NotUsed]
|
||||
}
|
||||
|
|
|
|||
|
|
@ -17,7 +17,8 @@ trait EventsByPersistenceIdQuery extends ReadJournal {
|
|||
* 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.
|
||||
* 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.
|
||||
*
|
||||
|
|
|
|||
|
|
@ -27,6 +27,13 @@ trait EventsByTagQuery extends ReadJournal {
|
|||
* 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 the `offset`. Otherwise, the read journal
|
||||
* should ensure that between an invocation that returned an event with the given
|
||||
* `offset` 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 in `offset`.
|
||||
*
|
||||
* 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.
|
||||
|
|
|
|||
|
|
@ -15,8 +15,11 @@ trait CurrentEventsByTagQuery extends ReadJournal {
|
|||
|
||||
/**
|
||||
* Same type of query as [[EventsByTagQuery#eventsByTag]] 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.
|
||||
* 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.
|
||||
*/
|
||||
def currentEventsByTag(tag: String, offset: Offset): Source[EventEnvelope, NotUsed]
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,8 @@ trait EventsByPersistenceIdQuery extends ReadJournal {
|
|||
* 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.
|
||||
* 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.
|
||||
*
|
||||
|
|
|
|||
|
|
@ -27,6 +27,13 @@ trait EventsByTagQuery extends ReadJournal {
|
|||
* 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 the `offset`. Otherwise, the read journal
|
||||
* should ensure that between an invocation that returned an event with the given
|
||||
* `offset`, 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 in `offset`.
|
||||
*
|
||||
* 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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue