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:
James Roper 2019-11-07 05:30:21 +11:00 committed by Helena Edelson
parent 365af7ee2f
commit 43ec699b77
6 changed files with 28 additions and 6 deletions

View file

@ -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]
}

View file

@ -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.
*

View file

@ -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.

View file

@ -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]

View file

@ -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.
*

View file

@ -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.