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 EventLog abstraction (implemented by AkkaPersistenceEventLog and KafkaEventLog). #14

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

odd
Copy link
Contributor

@odd odd commented Sep 27, 2017

No description provided.

Copy link
Owner

@krasserm krasserm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Odd, thanks for your contribution. I'm not sure if this is premature abstraction because of the semantic differences explained in the other comments. Do you have a specific use case for adding this abstraction?

*
* It is the application's responsibility to ensure that there is only a
* single materialized instance with given `persistenceId` writing to the
* journal.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an implementation detail of the Akka Persistence event log. Multiple materialization of a Kafka event log for the same topic partition can be made. Also, persistenceId refers to an implementation detail here.

* The source completes when the end of the log has been reached.
*
* During recovery, events are emitted as [[Delivered]] messages, recovery completion
* is signaled as [[Recovered]] message, both subtypes of [[Delivery]].
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A source from a Kafka event log continues to emit Delivered messages.

@odd
Copy link
Contributor Author

odd commented Sep 28, 2017

Hi Martin, during work on a sample application designed to test ways of caching running event sourced flows by identifier (to get functionality that mimics the behavior of persistent actors with auto passivation), the EventLog-abstraction seemed useful to abstract over this specific case:

EventSourcing(..).join(eventLog.flow[E](identifier))

(i.e. to be able to get an EventSourced flow over an EventLog without knowing the exact EventLog implementation). I have only used it with Akka Persistence event logs yet though, so it might not hold its ground.

Of course, documentation that is specific for Akka Persistence event logs (or Kafka event logs) should not be on the abstract event log but rather on each specific implementation. But if the semantic differences between the different implementations are too great as you say, I agree that the abstraction does not carry its weight.

Meanwhile, I'll keep the same abstraction in my cached-event-flow PR (yet to be pushed) and you can decide on it together with the rest at a later time (not too far off in the future I hope).

@krasserm
Copy link
Owner

I see, thanks for clarifying. I'm fine with updating the API docs of EventLog describing the degrees of freedom for implementations and then merge your PR.

@odd
Copy link
Contributor Author

odd commented Sep 28, 2017

Just to clarify, do you want me to clarify the degrees of freedom for implementations in this PR or do you want to add the clarifications yourself?

@krasserm
Copy link
Owner

@odd it would be great if you could do that. I actually meant: I'm fine if you update the API docs .. 😃. Thanks in advance!

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

Successfully merging this pull request may close these issues.

2 participants