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 :smile:
Would it be smart to pull them apart, make a generic EventSourcery::Reactor module that contains the interface?
Default the instantiation vars to use the Application.event_tracker, Application.projections_database, etc instead of hardcoding the postgresql ones?
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.
When refactoring my test-suite to use Memory instead of Postgres, my reactors start failing.
Reactors, typically have a form like
Problem is including the
EventSourcery::Postgres::Reactor
module. When I have event_source, sink, and _store set to in_meory variants that ship inevent_sourcer/lib/memory
, I get database-connection errors, since this reactor wants to push into the Postgresevent_store_database
or even theprojections_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 :smile:EventSourcery::Reactor
module that contains the interface?Application.event_tracker, Application.projections_database, etc
instead of hardcoding the postgresql ones?EventSourcery::Memory::Reactor
that defaults to the in-memory variants, be an option? Then the Reactors could hack around it with a: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.