Provide to(event_id) for reading events

[anderslemke]

In some cases, when replaying events, it's useful to replay until a certain event.

There already is the from(start) but I would also like to be able to say to(stop).

I would propose that the event used as the stop condition is not read.

I will be submitting a PR for this, but just wanted to air the thoughts here before starting working on it.

[paneq]

In some cases, when replaying events, it's useful to replay until a certain event.

Could you elaborate on those cases?

[anderslemke]

Yes. Of course 👍

In my case:

• I publish all saved events to RabbitMQ.
• handle events by consuming from RabbitMQ.

Let's say I want to send an email once when something happens. Also historically.

To do that; I would

1. put the consumer that actually sends mail into production; BUT
2. make sure it is not fetching events from RabbitMQ,
3. let events queue up in RabbitMQ
4. peek at the next event in RabbitMQ, and take note of the event_id for that event
5. replay all events from :head to event_id and send mails accordingly.

When the replay is done, I start the consumer on RabbitMQ, and let it catch up, sending mails for whatever might have happened since the consumer was taken down.

Now I have handled all historical events, and I'm up to date, and haven't missed a mail.

[paneq]

a) don't you need idempotency in the event handler?
b) if you had idempotent event handler then you could queue all events anyway and it would skip already processed ones.

I am not saying we don't need to(). Just sharing general knowledge around such problems @anderslemke 🙂

[anderslemke]

Thanks for sharing your knowledge @paneq .

Having an idempotent event handler would probably remove the need for both from()and to(). (Unless I'm missing some other use case for from() where idempotent event handling is not sufficient.)

But as you indicated, it's probably not the responsibility of this gem to mandate how you implement your event handlers. Idempotency is nice, but it's also more complex. And you might get similar and sufficient guaranties from other layers of your setup (RabbitMQ in our case).

IMHO this gem is about storing and reading events, and having a to()-method fits good with this responsibility.

[mostlyobvious]

In some cases, when replaying events, it's useful to replay until a certain event.

I've seen one of such cases recently, replaying events from given range for handlers that did not execute (failure mode). Without to in API it had to be done on repository level, that is EventStore::Repository::Event.where("id > ? AND id < ?", ...). I think having Client API for this use case is good addition.

[mostlyobvious]

I would propose that the event used as the stop condition is not read.

That seems to be consistent with from behavior 👍

[mostlyobvious]

I will be submitting a PR for this, but just wanted to air the thoughts here before starting working on it.

Looking forward to merge it when ready :)