R2DBC eventsBySlices query for projections with cluster singleton without entityType

Akka Persistence / Event Sourcing
1

Hi,
traditionally one could create a persisted cluster singleton e.g. using a PersistenceId.ofUniqueId(“abc”) which does not contain an entityTypeKey. As far I understand such entities can’t be projected using the eventsBySlices source provider as it needs an entityType as parameter?

Hence every entity that should be projected, no matter whether it’s a singleton or sharded entity, should use a PersistenceId which contains an entityType?

Cheers
Andreas

2

The slicing is there for partitioning the stream of events for a large number of entities over multiple parallel streams but keeping events from the same entity in the same partition.

This isn’t generally useful for a singleton, the events by persistence query would usually be enough.
Making up a entity type sounds like a reasonable way if you really want to do it anyway.

It would be interesting to hear about it if you have a use case where you think it makes sense to do slicing.

1 Like
3

Thanks for the explanation Johan! I have two main usecases:

  • Parallelising the projection for higher throughput
  • Easier abstraction for projection creation. Until now we had some wrapper code creating the cassandra projections which was the same no matter whether it was a sharded or singleton entity

But I guess you’re right, the first point is not that important for Singletons and the second one can still be accomplished even if it’s slightly more complex.

Thanks!

4

Another follow up @johanandren . To be able to use the existing offset store, it seems I’d have to implement my own SourceProvider as the only other existing one would be EventSourcedProvider.eventsByTag which is not supported by R2DBC (EventsByTagQuery · Issue #82 · akka/akka-persistence-r2dbc · GitHub).

I’ve created one using currentEventsByPersistenceId and Sequence based Offset here Scastie - An interactive playground for Scala.

Am I on the right track or is there another SourceProvider I’ve missed? Otherwise might it be worthwhile extending the existing SourceProvider so others can use projection with r2dbc on singletons with the built int offset store?

5

Thanks for the details, since both slicing and events by tag only partitions entities, not their individual entity event logs, that doesn’t seem useful for a singleton, unless you had a massive amount of singletons, or perhaps a number of persistent sharded daemon process actors that emit a lot of events.

I think for a single event log writing your own source provider backed by the events by persistence id query makes sense. There is nothing pre-built for this kind of use case.

1 Like