An in Memory Reactor module?

[berkes]

When refactoring my test-suite to use Memory instead of Postgres, my reactors start failing.

Reactors, typically have a form like

module Reactors
  ##
  # Sends the confirmation mail to a new registrant
  class ConfirmationMailer
    include EventSourcery::Postgres::Reactor


     process do
      # Do the hard stuff
     end
  end
end

Problem is including the EventSourcery::Postgres::Reactor module. When I have event_source, sink, and _store set to in_meory variants that ship in event_sourcer/lib/memory, I get database-connection errors, since this reactor wants to push into the Postgres event_store_database or even the projections_database (?).

One solution would be to build an in_memory variant of this reactor.

But, from what I can see, the EventSourcery::Postgres::Reactor has very little to do with Postgres and is mostly an API to emit events. Only the initializer of this module instantiates with defaults to Postgres. I don't understand why this is, and without that understanding, cannot offer a PR either 😄

1. Would it be smart to pull them apart, make a generic EventSourcery::Reactor module that contains the interface?
2. Default the instantiation vars to use the Application.event_tracker, Application.projections_database, etc instead of hardcoding the postgresql ones?
3. Alternatively, would a EventSourcery::Memory::Reactor that defaults to the in-memory variants, be an option? Then the Reactors could hack around it with a:

module Reactors
  ##
  # Sends the confirmation mail to a new registrant
  class ConfirmationMailer
    if MyMainApp.test?
       include EventSourcery::Memory::Reactor
    else
       include EventSourcery::Postgres::Reactor
    end
  end
end

I am probably not seeing the whole picture, and therefore misunderstand some points, but if someone can explain the reasoning behind making the reactors coupled to Postgres, I'd love to craft a PR that tackles this.