Supporting snapshots

[mbknor]

This tmp PR is based on https://github.com/NextGenTel/akka-tools/pull/22 but contains some changes.

In the original PR all users wanting to use snapshot'ing needed to do som "low level implementation". I cannot see any usecase for this...

In this PR all aggregates supports snapshoting - if you want to use it.

[IIlllII]

Thanks for the quick feedback :)

My original thinking around this in #22 , was that those messages can be of importance for the aggregate, and need to be handled differently depending on the type of aggregate.

With this, how can I customise SnapshotFailure message handling for example? Say I want to flip a health check to red on failing to make a snapshot.

In the usecase of destroying sensitive data, the aggregate could be modeled to make a choice whether to accept to process the snapshot request or not. It could reject snapshot request before it has enough changes applied, or before it is in some sink state which can safely be stored forever. I am not certain that logic belongs in the aggregate itself, but I am not sure where else to put it. Pointers on this would be great.

[mbknor]

You have some good points.. I'll think about it some more :)

[mbknor]

Some more thoughts...

This is actually more complicated.. I agree that user should decide if we can take snapshot.

But the saved snapshot cannot only be the user-state.. If you look in EnhancedPersistentActor, you see some state used to manage the internals (all the mutable variables).. This must also be included in snapshot.

When checking if we can save snapshot, we probably need to check some of these values as well.

I have to think more about "doing stuff when snapshot is saved". This has to be done BEFORE saving it - or including it in snapshot. because you are not guaranteed that the snapshotIsSaved-is called. This can happen: The snapshot is saved OK to repo but the app crashes before you get the callback about it.. when you start up, you reload state using the snapshot...

I have to think some more about this issue

[IIlllII]

As far as the EnhancedPersistentActor state goes, I added a naive start to storing the state in #22.

As far as the not snapshottable EnhancedPersistentActor states goes, is this related to the timer, and the DM stuff?

As far as doing stuff when snapshot is stored, the acceptSnapshotRequest in #22 was meant for validating only (only read, no update of any state). It was meant for gatekeeping from bad states getting stored from a user perspective. Changes to the state before an eventual snapshot is taken should go through a normal cmd/event flow right?

As far as the success/failure messages/callbacks not being guaranteed to be received/called is concerned, I think that is fine as long as the state that possibly snapshot is good. It should not matter whether one recovers from a snapshot or events right?

And if the user did not get information about it being a success he will probably retry/investigate.

My 2 cents anyway.