Introduce the concept of already actioned events to skip side effects in reactors

[twe4ked]

This is a WIP and may be force pushed still.

---

Changes

• Switch to DatabaseCleaner for truncation as some tables were getting missed
• Introduce a metadata (jsonb) column on the events table for storing causation_id and reactor_name
• Introduce a new last_actioned_event_id column on the projector_tracker table

Process

• When an event is emitted from a reactor we:
  • Store the id of the event that was reacted to along with the reactor name in the `metadata of the event
  • Store the id of the event that was reacted to in the last_actioned_event_id column on the projector_tracker
• When we go to emit an event we check to see if the event being reacted to's id is less than the value in last_actioned_event_id and if it is we ignore the event
• When the reactor is setup if the last_actioned_event_id is 0 we query the events table and attempt to find the most recent causation_id stored in the event metadata. If we find one we set last_actioned_event_id to that value

This is probably better explained by the code or by @vonconrad's comment here: https://github.com/envato/event_sourcery/issues/24#issuecomment-297965493 (See 3.2).

TODO

• [ ] Move testing to better levels, some of the reactor level tests should be at the tracker level
• [ ] Fix CI
• [ ] Store metadata in EventStoreWithOptimisticConcurrency#write_events_sql

Fixes https://github.com/envato/event_sourcery/issues/24.

[twe4ked]

Based on the Buildkite agent tags we're running Postgresql 9.3 (postgresql=9.3). Sounds like JSONB support was added in 9.4 so we will need to upgrade if we want to test with JSONB.

[orien]

I know of a few Event Sourcery applications with reactors that emit events via commands/aggregates. How can we support this use case?

[twe4ked]

I know of a few Event Sourcery applications that emit events via commands/aggregates. How can we support this use case?

@orien I may be misunderstanding but unless they're doing that in reaction to an event I don't think this applies.

[orien]

@twe4ked I had edited that comment to be more clear. But I mean exactly that, from a Reactor.

I know of a few Event Sourcery applications with reactors that emit events via commands/aggregates. How can we support this use case?

[twe4ked]

Ah, so you mean the reactors don't use emit_event? Not sure of an easy way to handle that off the top of my head.

[orien]

Yeah, exactly. Sorry to throw a spanner.

[twe4ked]

Closing this as it's really related to https://github.com/envato/event_sourcery-postgres at this point. Also there still seems to be some unsolved problems and differing opinions over how this should work. Until another time! Thanks for all the reviews.