Allow subscriptions to receive the stream name

[mlh758]

First off, this library seems well thought out and comprehensive. Thank you for providing it.

In the documentation for subscriptions it shows the subscriber being called with only the event. When using the library for event sourcing though, it seems like the stream name is what uniquely identifies the entity. When building a projection, it would be helpful to have that unique identifier in context to apply the event to the existing projection. Even just to be able to load and play the stream forward in response to an event in the callback.

It seems like the code responsible for publishing would have it available. Is this feasible? Is it reasonable? I could probably submit a PR with a little bit of guidance.

I can work around this by including the necessary IDs in each event or by using the event ID and the type to look the stream up but just having it in context right away would just be easier.

[mpraglowski]

Hi. Thanks for your idea.

When using the library for event sourcing though, it seems like the stream name is what uniquely identifies the entity.

Yes. In this case a stream of events represents all changes made in aggregate state. All events from the stream will be used to rebuild aggregate state next time it will be loaded.

When building a projection, it would be helpful to have that unique identifier in context to apply the event to the existing projection.

I'm not sure if I get the idea here. Could you share some example?

Even just to be able to load and play the stream forward in response to an event in the callback.

We are using this pattern with our implementation of process managers (see sample implementation in the eCommerce project here https://github.com/RailsEventStore/ecommerce/blob/master/infra/lib/infra/process_manager.rb). However we do not depend on the original stream where event is written - each time a new event is handled by process manager (building projection based on past events) we link it to the process stream (projection stream) what allows us to replay them next time process manager is triggered.

It seems like the code responsible for publishing would have it available. Is this feasible? Is it reasonable? I could probably submit a PR with a little bit of guidance.

Any PR will be welcomed - event as a discussion starting point. Please take a look at my PR #1860 where I separate the persistence & pub/sub parts even more by introducing topics (like in Amazon SNS or Google Pub/Sub). This is still just an idea so any feedback will be appreciated.

I can work around this by including the necessary IDs in each event or by using the event ID and the type to look the stream up but just having it in context right away would just be easier.

Show me the code ;) I would love to understand your use case.