Closed binarytemple closed 1 year ago
How many dynamic event store instances were you expecting to be running at the same time?
Currently there are many auxiliary processes started by the event store supervisor which use the event store name as part of the child process' name, such as the Postgres database connection. See EventStore.Supervisor
. Unfortunately this means that reducing the runtime atom usage to zero would require a significant refactoring of these process names to not use atoms, as well as the event store supervisor process itself.
Hi Ben, let's close this out, I was working with a client and they are happy to have 400+ atoms added per event (and they tend to have new event specific event stores several times a week). The event store atom creation is the least of their problems.
Hi Ben, I've been looking at EventStore from the perspective of dynamic eventstore creation for an application with a potential lifespan of several years.
Anyhow, what we noticed is that the eventstore uses an atom for the eventstore name and this percolates through the system, for example
EventStore.all_instances/0
usingProcess.whereis(name)
(which only works with atoms).The risk is that we will exhaust the atom table limit, we could just increase the maximum size, but that comes with its downsides. and atoms are really only intended for things that would be defined in code, ideally, at runtime, our atom allocation would be zero, as is considered best practice in the Erlang community.
I wonder if you'd be open to a PR which modified EventStore so that it would work with
:name
where name is an atom or binary, for example, by using an instance ofRegistry
and performing lookup using:via
tupple likename = {:via, Registry, {Registry.Commanded.EventStore, name}}
?What do you think, is this something you'd be willing to accept?