6

PersistentView has been deprecated in akka 2.4. The docs advise to switch to PersistenceQuery instead. However PersistenceQuery seems to be limited to the event journal only, without a capability to query the snapshot store.

Restoring a state from a large number of events takes some time, so the ability to use snapshots is important for me.

Is the deprecation a bit ahead of its time here? Should I continue to work with PersistentView or am I missing something? How do I work with snapshots using only PersistenceQuery?

Thank you

kostja
  • 60,521
  • 48
  • 179
  • 224
  • Snapshots will be used (if you take them and if you configure your system to use them) when recovering a persistent entity during the `receiveRecover` phase to get the state of that actor recovered faster. I don't see why you would want to query a snapshot store. Something using persistence query (like CQRS when building a read model) should need individual events and not an aggregated state snapshot. – cmbaxter Aug 15 '16 at 17:27
  • Creating a read model is exactly my use case. Of a large number of infrequently used views with passivation in an LRU. With `PersistentView`, the read model can manage its own snapshots, which are then used to recreate its state when needed. Recovery from (snapshot + last X events) allows for a better latency than recovery from (all events). Your comment seems to imply that snapshots are not a good fit for a read model. Care to elaborate? – kostja Aug 15 '16 at 18:50
  • The read models I have built as part of Event Sourcing and CQRS are long lived and stored in a completely storage engine from the persistence journal (that being Elasticsearch). The read model builders listen to the live event streams (by tag) and project the events into representations of the entities that live in ES for the purpose of querying. The events themselves work perfectly fine for building out the read models this way. A snapshot might only be useful if I was behind by many hundreds of events for a particular entity or if I needed to rebuild the entire read model again – cmbaxter Aug 15 '16 at 20:03
  • Also since you probably don't snapshot after each event then if your read model is based on snapshots it will be out of date in between snapshot periods. – cmbaxter Aug 15 '16 at 20:05
  • I see. Further decoupling reads & writes sounds sensible. I will take a look into it since ES is part of the picture anyway @consistency - the read model uses snapshots for recovery only, augmented by the most recent events. Until evicted, it relies on the autoupdate interval and event journal for reasonable consistency. Thanks for the hints. – kostja Aug 15 '16 at 20:28

1 Answers1

1

One way to do it:

  • Make the Actor you use as the "PersistentView" extend a PersistentActor.
  • Store your PersistentQuery offset in the state of the PersistentActor and save snapshots regularly.
  • Initially set query offset to the earliest offset.
  • In the receiveRecover set the query offset to the offset stored in the PersistentActor snapshot.

Example: https://github.com/benniekrijger/todo-service/blob/master/src/main/scala/com/todos/repository/TodoRepositoryView.scala

Bennie Krijger
  • 595
  • 7
  • 10