Skip to content
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

Add Sink to extension as a writer endpoint #42

Open
scullxbones opened this issue Aug 25, 2015 · 5 comments
Open

Add Sink to extension as a writer endpoint #42

scullxbones opened this issue Aug 25, 2015 · 5 comments

Comments

@scullxbones
Copy link
Owner

Closes flow for ReadJournal queries to write to journal

@matheuslima
Copy link
Contributor

Can you explain better this issue?

@scullxbones
Copy link
Owner Author

So this would be something in the extension (I guess?) that would provide a Sink to stream journal events into. It would be useful if you were running two of these journals (for example) and wanted to transfer one journal into the other - just run an allEvents read journal query and tie it to the sink of the second journal to transfer the data. I guess just a Sink[EventEnvelope] that ran through the regular journal append path would be good for now. Ideally the journal append path should probably be an adapter on top of a Sink, to push everything towards streams and away from ad-hoc.

@matheuslima
Copy link
Contributor

" It would be useful if you were running two of these journals (for example) and wanted to transfer one journal into the other"
This is for migration journal proposals? Or migration some events from a journal to another.

@scullxbones
Copy link
Owner Author

That's the use case I have in my head, but it's also deeper than that. I think that it would be good to rebuild the write side of the journal on top of Akka streams for the advantages (like backpressure).

If we ignore deletes for now, there are two parts to the write side:

  • Append - fufilled by a Sink
  • Replay - fulfilled by the EventsByPersistenceId query

Exposing a Sink could be a good start towards re-building the base layer. I think this could end up cleaning up the code as well, moving more into the common project.

@matheuslima
Copy link
Contributor

Wow, it's awesome! The plugin would become fully async, non-blocking and backpressured.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants