Allow duplicate keys in DefaultProgrammaticDriverConfigLoaderBuilder

Description

This issue came up in a Spring Boot context.

Since DefaultProgrammaticDriverConfigLoaderBuilder is based on NullAllowingImmutableMap, the map builder would reject any duplicate keys.

This may be too restrictive for systems where various independent components all get a chance to enrich the config with more settings, with some potential overlap.

Granted, if duplicate keys are allowed we open the door for non-deterministic behavior. But I'd argue that 1) this is already the case with the OptionsMap API – and 2) application correctness is not a driver concern after all.

Environment

None

Pull Requests

None

Activity

Show:
Alex Dutra
November 19, 2020, 4:37 PM

I'm going with the simplest solution that would allow to unblock the Spring Boot issue – even if Spring Boot would be an excellent candidate for switching to OptionsMap, but that's a bigger change that won't be implemented soon.

Alex Dutra
November 19, 2020, 3:41 PM

Hmm thinking about this a bit more, I think deprecation is a bit overkill. Users may want to override a few options programmatically while still keeping the TypeSafe Config machinery around, for example to apply system properties overrides and/or to use a common application.conf file with the most common options that never change.

These use cases seem valid to me and I don’t think it’s legit to deprecate them.

Alex Dutra
November 19, 2020, 3:27 PM

Agreed, with and both solved, indeed it seems natural to deprecateDefaultProgrammaticDriverConfigLoaderBuilder and evangelize around DriverConfigLoader.fromMap as a better alternative.

Olivier Michallat
October 15, 2020, 5:21 PM

I think we should also deprecate DefaultProgrammaticDriverConfigLoaderBuilder. DriverConfigLoader.fromMap is a better alternative, but the message has not been communicated clearly enough.

Fixed

Assignee

Alex Dutra

Reporter

Alex Dutra

Fix versions