[erlang-questions] Use of application environment

[Michael Radford]

A related question....  This is an issue that often makes me resort to
stopping and starting my applictions on upgrade, even when it should be
easy to avoid.

It seems that release_handler:eval_appup_script/4 first evaluates the
upgrade script directives (reloads modules, calls code_change handlers,
etc.), and then afterward changes the application configuration and
calls config_change.  Perhaps there's a good reason for this order.

But in any case, this means that if you add a new application
environment variable controlling some new behavior of a server, it won't
be available when the server's code_change hander is called.  So the
obvious way of doing things (in code_change, read the value of the new
variable and use it to transform the state) will crash.

Is there an easy way to work around this?

My only idea was to have code_change put the server into a temporary
state where it's waiting for the application's config_change handler to
be called, and then Application:config_change somehow knows about a list
of gen_servers (etc.) to call with the new configuration.

Maybe this could be handled generically by an extension to gen_server.
It would be nice to be able to write
  code_change (OldVersion, EnvChanged, EnvNew, EnvRemoved, State, Extra)
and do all the transformations in one place.

Mike


Edwin Fine writes:
> Hi all,
> 
> Is it considered bad practice to use application environment variables (i.e.
> application:get_env/2,3) in workers, as opposed to only passing config
> information via the start()/init() calls? I am finding it tedious as I add
> more configuration data to the sys.config file, to get_env() the data in a
> supervisor and then parcel it out to the workers. Also, it becomes a pain to
> change the values at runtime, whereas if I put a function like this in an
> affected worker
> 
> my_foo_val() ->
>     application:get_env(my_app, my_foo_val, ?SOME_SANE_DEFAULT).
> 
> then runtime changes can be made immediately using set_env(), and it becomes
> much easier to add new config data, but I feel uneasy, almost as if I'm
> using global variables. From a load point of view, I only do this in places
> where the value is not used at a high rate.
> 
> What is the preferred or recommended (or even most common) practice?
> 
> Regards,
> Edwin Fine