Issue
- The commandline for mounting a backend can be very long
- A specification is already used for code generation, but
- the data is not available in KDB
- the specification cannot be used for mounting, even though the needed information is in the specification
Constraints
- the specification must be simple to use
- there must be a clear mapping between keys and configuration file entries
- there must be a 1:1 mapping of keys used within an application and the specification
Assumptions
- The user will have a variable for each configuration value (e.g. by using a binding) if she cares about access performance
- memory footprint is expected to be low
Considered Alternatives
- modifying kdbGet() and ksLookup() so that we get a logical hierarchy
- having a duplicated in memory hierarchy with the cascaded key sets
Decision
Argument
- The user wants deterministic retrieval of configuration. It must be answerable (w/o study of source code and debugging) which value will be used in the current situation.
Implications
- Introduction of spec/ hierarchy
- kdbGet() for cascading
- kdbSet() for cascading
- modify ksLookup() for cascading
- KDB_O_DEFAULT in ksLookup()
- define necessary metadata
- mounting spec files
Related decisions
Notes
