-
Notifications
You must be signed in to change notification settings - Fork 1
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
Introducing projections #8
Conversation
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.
looks like a good starting point that can be merged (soon)
}, | ||
"iot-service-projection", | ||
registration::EVENTS_TOPIC, | ||
); |
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.
Might be missing the slice range that this projection should handle, but slices can come later in a separate step and we start with all slices.
Corresponding jvm example https://doc.akka.io/docs/akka-projection/current/r2dbc.html#running-with-sharded-daemon-process
or with grpc https://doc.akka.io/docs/akka-projection/current/grpc.html#consumer
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.
btw, here is the jvm code for slice ranges https://github.com/akka/akka/blob/8011e8e2de56502771336140a1c1dd84d3b97de6/akka-persistence/src/main/scala/akka/persistence/Persistence.scala#L446-L478
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.
TBH, I've not put a ton of consideration into the slice mechanism just yet. I'll tackle that with the next PR as you suggest.
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.
LGTM
Here are the traits and types being proposed. These correspond reasonably well with their JVM counterparts but with the queries conflated into the providers as discussed offline:
Along the way, I've also dropped the naming of
Record
for entities and now useEventEnvelope
, which is consistent with its use elsewhere.TODO (in another PR):