-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
+per #16541 initial version of the Persistence Query module #18051
Conversation
Refs #16541 |
Test FAILed. |
Error lines in https://jenkins.akka.io/job/pr-validator-per-commit-jenkins/3269/:
|
query has an optionally supported offset parameter (of type ``Long``) which the journals can use to implement resumable-streams. | ||
For example a journal may be able to use a WHERE clause to begin the read starting from a specific row, or in a datastore | ||
that is able to order events by insertion time it could treat the Long as a timestamp and select only older events. | ||
Again, specific sapabilities are specific to the journal you are using, so you have to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
capabilities
LGTM. Very clean API! |
//#events-by-tag-publisher | ||
class MyEventsByTagPublisher(tag: String, offset: Long, refreshInterval: FiniteDuration) | ||
extends ActorPublisher[EventEnvelope] { | ||
import MyEventsByTagPublisher._ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’d declare the case object Continue
in here to avoid having to pull the companion into the docs as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
|
||
``EventsByPersistenceId`` is a query equivalent to replaying a :ref:`PersistentActor <event-sourcing>`, | ||
however, since it is a stream it is possible to keep it alive and watch for additional incoming events persisted by the | ||
persistent actor identified by the given ``persistenceId``. Most journal will have to revert to polling in order to achieve |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/journal/journals/
LGTM, after final touch |
Gotta love collaboration, feedback is great 👍 😄 |
9b404d8
to
e0c7aec
Compare
Addressed all feedback, merging after validation (failure was my javadoc mistake) |
Test FAILed. |
e0c7aec
to
3314de4
Compare
Test FAILed. |
Test PASSed. |
+per #16541 initial version of the Persistence Query module
@@ -0,0 +1,172 @@ | |||
adoc-api/akka/persistence/query/scaladsl/ReadJournal.html... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unnecessary log file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ladies and Gentlemen,
Thanks to the Akka Streams 1.0 release last week, we now would like to present this new experimental module for initial feedback, addressing a long history of discussions and awesome feedback we have gathered from the community (see the great summary: Akka Persistence on the Query Side: The Conclusion).
Introducing the Akka Streams based improved Query Side to Akka Persistence.
This is only the initial PR, more examples, polish and example implementations will be pushed soon.
The current form of the API is the culmination of these discussions with the community, a very long "maturing in the back of your mind" process and a few days spent together around ScalaDays for polishing and trying it out in various example/mock implementations with @patriknw and @dotta.
The API is intentionally very "open" (we provide the marker traits
Query[T, M]
,Hint
, and a number of basic case classes), because we do not want to restrict some of the great journals out there - instead, we want to encourage various implementations to expose that kind of API which is best suited for the underlying store. For example, SQL based journals may provideSqlQuery("SELECT * ...")
if that's what they want to expose. Journals will have to document their behaviours very thoroughly.Other important information:
akka-persistence-query-experimental
) will be (and stay) experimental in Akka2.4
ReadJournal
implementations, however we currently do not intend to maintain one for production usage - we ask the community to help out, similarily like it has happened organically with Akka Persistence.EventAdapter
s known from the write-side in Akka 2.4 is under discussion/development Integrate EventAdapters to the Query side #18050