The existing client libraries (we’re using the Java one) has support for telling a subscriber that a subscription is now “live”, e.g. has switched from catch up mode to updating in response to new events coming in. There are posts elsewhere on this forum from years back regarding how this can be useful, I appreciate that there’s no guarantee that you have “all” events at any given point, but this functionality is still something that we leverage on our platform as a signal that a long running replay/rebuild has completed and we can now rely on the data being fresh.
I do not see any similar flag or callback in the new gRPC based Java client. Is it there and I’ve missed it, or if not, are there any plans on supporting it? Would doing so be a client side change only or require a new version of EventStoreDB?
1 Like
Hey @Kristian_Freed,
The current Java client version doesn’t expose it but on every notification of an event, the server gives you the first and last event number of the stream you are subscribed to. You should be able to replicate the behavior you are looking for with it.
I can find some time to add those missing parts this week.
If those “first and last” event versions could be exposed as part of the event record, that would definitely be enough to cover our needs and would be very much welcome!
Would these be exposed also in the case of reading? The ESJC client that we currently use exposes explicitly whether you have hit the “end of stream” in a read which we rely on for paging. In the gRPC client, I suppose the way to check for this is to see if a read returns fewer than the requested events?
Thank you, this is useful (though the Java client has some behaviour differences it seems, like using exceptions for “not found” instead of a status).
If it’s possible to avoid antother call back to eventstore for every event to compare versions however, that would be preferable, so adding these versions as part of the event updates would help.
On the example using paging, we do rely on the paging pattern not only for the reading of events themselves, for also running in-process operations on events in a batched manner (read 100 events, process 100 events, throw away the events, go back for more), so the explicit paging pattern is still useful to us.