tompave/fun_with_flags

Allow different persistence adapters per env

Orevarc opened this issue · 2 comments

Orevarc commented

Currently, if you specify :redis config options in your main config, there is no way to overwrite this config in a different environment. For example, when writing a test config and overriding the adapter defined by :fun_with_flags, :persistence, the adapter gets overwritten but it still attempts to make a connection to a Redis instance as there is still the :fun_with_flags, :redis config that is defined on the main config file but not in say a test.exs config.

ie
config.exs

  config :fun_with_flags, :redis,
    host: <host>
    port: <port>

test.exs

config :fun_with_flags, :cache_bust_notifications, enabled: false

config :fun_with_flags, :persistence, adapter: MyApp.CustomFlagStore

Merged config would be the following:

#Still attempts to connect to redis as this is defined even though a non redis adapter is defined below
  config :fun_with_flags, :redis, 
    host: <host>
    port: <port>

config :fun_with_flags, :cache_bust_notifications, enabled: false

config :fun_with_flags, :persistence, adapter: MyApp.CustomFlagStore

Specifying a customer persistence adapter should not attempt to make a connection to ecto or redis

tompave commented

Hi, thank you for using the library and for opening this issue.

Questions: what version of FWF are you using? And what version of Elixir and OTP?

About what you describe:

Currently, if you specify :redis config options in your main config, there is no way to overwrite this config in a different environment.

That should work, with caveats. Before we look into that, and assuming that there is a bug with the config loading code, a simple solution to get you unblocked is to configure FWF in the env specific files. So instead of configuring it in config.exs and then in test.exs, you could instead put all your FWF configuration into prod.exs, dev.exs and test.exs. Maybe it's not ideal, but it would ensure proper separation.

Moving on, I said that this should work but with caveats. Basically, in order to load the env specific overrides your config/config.exa file should end with a call to Config.import_config/1 (or its older deprecated Mix precursor: Mix.Config.import_config/1). It's important that that call is the last instruction in the file. If things are not working in your application then it's worth checking that that's the case.

Merged config would be the following:
...

Yes, those snippets should be correct, and with that config the Redis adapter should not be started.

You can verify what the current config is with Application.get_all_env(:fun_with_flags), and you should be able to check it in a test with iex -S mix test.

You should check what the current configured adapter is, using FunWithFlags.Config.persistence_adapter(). Then check what got compiled into the application modules with FunWithFlags.Store.Persistent.adapter(). If those are different, then it would be a case of this. To fix it, run: rm -r _build/test/lib/fun_with_flags.

  • 👍1
Orevarc commented

FWF: 1.4.1, OTP: 21

file should end with a call to Config.import_config/1

Yes, that's how it is setup.

FunWithFlags.Config.persistence_adapter() != FunWithFlags.Store.Persistent.adapter(). Removing build files and re-compiling for that env worked. I just didn't read that far into the README 😅 Sorry about that. Would have saved me a headache. Thanks for the quick and thorough reply!

  • 👍1