\label{doc_help_elektra-cascading_md_md_doc_help_elektra_cascading}%
\Hypertarget{doc_help_elektra-cascading_md_md_doc_help_elektra_cascading}%
 {\bfseries{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 {\itshape system configuration} regarding the user\textquotesingle{}s needs in the {\itshape 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 {\ttfamily /} such cascading will automatically be performed.\hypertarget{doc_help_elektra-cascading_md_autotoc_md2358}{}\doxysection{SPEC}\label{doc_help_elektra-cascading_md_autotoc_md2358}
Keys in {\ttfamily spec} allow us to specify which keys are read by the application, which fallback it might have and which is the default value using metadata. The implementation of these features happened in {\ttfamily ks\+Lookup}. When cascading keys (those starting with {\ttfamily /}) are used following features are available (in the metadata of respective {\ttfamily spec}-\/keys)\+:


\begin{DoxyItemize}
\item {\ttfamily override/\#}\+: use these keys {\itshape in favor} of the key itself (note that {\ttfamily \#} is the syntax for arrays, e.\+g. {\ttfamily \#0} for the first element, {\ttfamily \#\+\_\+10} for the 11th and so on)
\item {\ttfamily namespace/\#}\+: instead of using all namespaces in the predefined order, one can specify which namespaces should be searched in which order
\item {\ttfamily fallback/\#}\+: when no key was found in any of the (specified) namespaces the {\ttfamily fallback}-\/keys will be searched
\item {\ttfamily default}\+: this value will be used if nothing else was found
\end{DoxyItemize}

They can be used like this\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{kdb set /overrides/test "{}example override"{}}
\DoxyCodeLine{sudo kdb meta-\/set spec:/test override/\#0 /overrides/test}

\end{DoxyCode}
\hypertarget{doc_help_elektra-cascading_md_autotoc_md2359}{}\doxysection{CASCADING}\label{doc_help_elektra-cascading_md_autotoc_md2359}
When cascading keys (those starting with {\ttfamily /}) the lookup will work in the following way (it can be debugged with {\ttfamily kdb get -\/v})\+:


\begin{DoxyEnumerate}
\item In the {\ttfamily spec}-\/key the {\ttfamily override/\#} keys will be considered.
\item If, in the {\ttfamily spec}-\/key, a {\ttfamily namespace/\#} exist, those namespaces will be used.
\item Otherwise, all namespaces will be considered, see \mbox{\hyperlink{doc_help_elektra-namespaces_md}{here.}}
\item In the {\ttfamily spec}-\/key the {\ttfamily fallback/\#} keys will be considered.
\item In the {\ttfamily spec}-\/key the {\ttfamily default} value will be returned.
\end{DoxyEnumerate}

See \mbox{\hyperlink{doc_tutorials_application-integration_md}{application integration}} for how to use cascading names in the context of applications.

\mbox{\hyperlink{doc_help_elektra-namespaces_md}{Read more about namespaces.}} 