About Snapshots

[wvandermerwe]

Hi, firstly thanks for publishing this library, was very interesting reading the docs and looking at the code!

From what I can tell, the snapshot table is not created transactionally with the other tables like the journal etc.

My question is, is this the same for inserts? Ie, will snapshots be inserted atomically alongside the other tables?

Also, can snapshots be inserted/updated after every successful command/event? In order to derive some Postgres views from this in the same DB, thus not needing projections in other processes/DBs.

[hnaderi]

Hi, firstly thanks for publishing this library, was very interesting reading the docs and looking at the code!

Hi @wvandermerwe , glad to hear that!

From what I can tell, the snapshot table is not created transactionally with the other tables like the journal etc.

My question is, is this the same for inserts? Ie, will snapshots be inserted atomically alongside the other tables?

It depends on what variation of the state machines you want to use.

1. If you want to use event sourcing (Edomaton), the answer is No. the event sourcing snapshot is completely separate and is updated after the transaction in a monotonic fashion. It's used as a cache and can be purged at will with no impact but possible performance loss due to cache misses.
   The default one is in-memory and a persisted one can also be enabled.
2. If you want to use the CQRS one (Stomaton), the answer is Yes. actually the CQRS one doesn't have a snapshot, and is a write-side event-sourcing pattern, where events are used as a way to update the database in the way you mentioned. You can implement your own custom event handler and register it in the backend. See the code here

Also, can snapshots be inserted/updated after every successful command/event? In order to derive some Postgres views from this in the same DB, thus not needing projections in other processes/DBs.

However, if you want a hybrid approach, with event-sourcing and in-transaction event handling, you can override the default storage drivers or even implement yours from scratch. It's not hard, but is better reserved as a last effort, as they require more implementation and will decrease expressiveness of the code, that is one of the goals of this library.