EventsByTag support

Support EventsByTag query in read journal

[scullxbones]

@marcuslinke ok i see what you mean with duplication:

Additionally there could be multiple journal entries within the same timestamp. Which one would be addressed by a specific offset especially if you think of the possibility that an additional event for that timestamp might occur later? In this case we probably have to replay ALL events with that specific offset which may lead to events duplicated in the view.

So on write, we’ll create the timestamp. We can look into a migration in the future to back-propagate this (and potentially add tags, and add insertion order sort to AllEvents), but don’t want to bite off too much now. When a user runs the query they can hold onto the timestamp they care about, and you’re right - it may cause them to see “more events” than they’d like. For this initial release, idempotency/“at least once” will be a requirement for users of EventByTag. It can cause duplication on multiple runs, but not lost data since the only way a user will know the offset is via running EventByTag at least once.

@filosganga I agree, it would only affect those two queries, not recovery. sequenceNr isn’t leaving, that needs to continue to drive recovery - that’s a critical part of akka-persistence behavior.

[marcuslinke]

@filosganga I agree. This is specific to EventByTag and AllEvents. So it does matter in the context of this issue. 😉