Elektra  0.8.16
elektra-cascading(7) -- of key names

Cascading is the triggering of secondary actions. For configuration it means that first the user configuration is read and if this attempt fails, the system configuration is used as fallback.

The idea is that the application installs a configuration storage with default settings that can only be changed by the administrator. But every user has the possibility to override parts of this system configuration regarding the user's needs in the user configuration. To sum up, besides system configuration, users have their own key databases that can override the settings according to their preferences.

Thus when a key starts with / such cascading will automatically performed.

Keys in spec allow us to specify which keys are read by the application, which fallback it might have and which is the default value using meta data. The implementation of these features happened in ksLookup. When cascading keys (those starting with /) are used following features are available (in the meta data of respective spec-keys):

They can be used like this:

    kdb set /overrides/test "example override"
    sudo kdb setmeta spec/test override/#0 /overrides/test

CASCADING

When cascading keys (those starting with /) the lookup will work in the following way (it can be debugged with kdb get -v):

  1. In the spec-key the override/# keys will be considered.
  2. If, in the spec-key, a namespace/# exist, those namespaces will be used.
  3. Otherwise, all namespaces will be considered, see here.
  4. In the spec-key the fallback/# keys will be considered.
  5. In the spec-key the default value will be returned.

See application integration for how to use cascading names in the context of applications.

Read more about namespaces.