nickva commented on code in PR #4813:
URL: https://github.com/apache/couchdb/pull/4813#discussion_r1408705136
##########
src/config/src/config.erl:
##########
@@ -315,6 +315,19 @@ handle_call({delete, Sec, Key, Persist, Reason}, _From,
Config) ->
_ ->
ok
end,
+ % If persistent, there will always be a delete marker just written
+ % in the last .ini file, so only reload in the non-persistent case.
+ Persist orelse
+ begin
+ IniMap = ini_map(Config#config.ini_files),
+ case maps:find({Sec, Key}, IniMap) of
+ % ?DELETE markers not inserted
+ {ok, Val} when is_list(Val) ->
+ true = ets:insert(?MODULE, {{Sec, Key}, Val});
+ _ ->
+ ok
+ end
Review Comment:
The goal of the `Persist = false` I think would be do everything the same as
`Persist = true` except write to file. That seems like the simplest description
of its behavior. The immediate effects on the "live" config value should be
exactly the same, so if a user does:
`config:set("section", "key", "value", true)` or `config:set("section",
"key", "value", false)`, the live value would be `"value"`. If they do
`config:delete("section", "key", true)` or `config:delete("section", "key",
false)` the live value would be the code default (config returns `undefined`).
After a restart or reload, the live value may change (it may be whatever was
in the files) but that's something the user explicitly requested by using he
`Persist = false` modifier.
Only in the `Persist = true` (the default) case, we'd want to have
idempotence between any number of restarts or reloads after setting or deleting
a value.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
