Storing system configuration parameters

Say If my system has a log cleaning function that user can specific the cleaning interval log_clean_interval = 7

I can

  1. store it in config/config.exs and retrieve with System.get_env("log_clean_interval"). If the interval is changed, I believe I have to run the deployment process again to push changes to production.

  2. store it in a database and query it like SELECT * from config_data where code ='log_clean_interval'

How do you guys handle this problem that update parameters easily?

Hello @chungwong,

For this case I would recommend to put the changeable configuration away from the source code and more away from config files. Since elixir/erlang is compiled language, once it’s compiled I don’t think that it will reread the config files again, especially when you create a release using distillery or exrm.

You could fetch from a db. after some time interval if you want it to update after some time interval.
Dev

– Further Updated
Even, if it’s interpreted language, we should keep changeable configuration (which is changed during the run time) away from the source file, So that we do not recompile or reinterpret small changes to update the small configuration changes.

1 Like

Another option is to use ETS - backfill on init.

If you need to access this a lot? You should compare performance. Probably need to use ETS anyway at least for cache.

If you’re running the app on distributed erlang cluster and deploying with erlang way? Then probably should not use system env.

If the app already uses database and there are more updatable config? Use database, probably with cache in ETS.

1 Like

Database + ETS for caching sounds great.
I believe ETS doesn’t work on cluster if I remember correctly. Should I consider Mnesia instead?

DETS works for cluster, as it stands for Distributed Erlang Term Storage…

But it is not as fast as ETS.

Dets is disk based ets, and AFAIK is not distributed. You need mnesia for distribution

2 Likes

Oh sorry, thanks for correcting…

I would store configuration in the Application environment, you can seed it with defaults in config.exs, you can then build functions for updating this from whatever source you got