This tutorial assumes that you know what \hyperlink{doc_tutorials_namespaces_md}{namespaces} are. We will only be talking about \hyperlink{md_doc_help_elektra-cascading_doc_help_elektra-cascading_md}{cascading lookup} here.

In Elektra, the default order of namespaces is as follows\+:


\begin{DoxyItemize}
\item \href{https://github.com/ElektraInitiative/libelektra/blob/master/doc/help/elektra-namespaces.md#spec}{\tt spec} (contains metadata, e.\+g. to modify elektra lookup behaviour)
\item \href{https://github.com/ElektraInitiative/libelektra/blob/master/doc/help/elektra-namespaces.md#proc}{\tt proc} (process-\/related information)
\item \href{https://github.com/ElektraInitiative/libelektra/blob/master/doc/help/elektra-namespaces.md#dir}{\tt dir} (directory-\/related information, e.\+g. {\ttfamily .git} or {\ttfamily .htaccess})
\item \href{https://github.com/ElektraInitiative/libelektra/blob/master/doc/help/elektra-namespaces.md#user}{\tt user} (user configuration)
\item \href{https://github.com/ElektraInitiative/libelektra/blob/master/doc/help/elektra-namespaces.md#system}{\tt system} (system configuration)
\end{DoxyItemize}

Looking at this order, we can see that if a configuration option isn't specified by the user (then it would be in the {\ttfamily user} namespace), it will be loaded from the {\ttfamily system} namespace. In this case, the option in the {\ttfamily system} namespace will be used if the key hasn't been defined by the user.

``` \$ sudo kdb set system/sw/tutorial/cascading/\#0/current/test \char`\"{}hello world\char`\"{} create a new key system/sw/tutorial/cascading/\#0/current/test with string hello world

\$ kdb get /sw/tutorial/cascading/\#0/current/test hello world

\$ kdb set user/sw/tutorial/cascading/\#0/current/test \char`\"{}hello universe\char`\"{} Create a new key user/sw/tutorial/cascading/\#0/current/test with string hello universe

\$ kdb get /sw/tutorial/cascading/\#0/current/test hello universe ```

Furthermore, in the order {\ttfamily dir} is even higher than {\ttfamily user}, which means that configuration in the current folder can overwrite user configuration.

{\ttfamily .configuration} in your current directory\+:

``` test = hello dir ```

Then run\+:

``` \$ sudo kdb mount /.configuration dir/sw/tutorial/cascading/\#0/current ini \$ kdb get /sw/tutorial/cascading/\#0/current/test hello dir ```

\subsection*{Cascading}

Cascading triggers actions when, for example, the key isn't found. This concept is used for our previous example of using {\ttfamily system} configuration when the {\ttfamily user} configuration is not defined. When a key starts with {\ttfamily /}, {\itshape cascading lookup} will automatically be performed. e.\+g. using {\ttfamily /test} instead of {\ttfamily system/test} will do a cascading lookup.

\subsection*{Override links}

The {\ttfamily spec} namespace is special as it can completely change how the cascading lookup works.

For example, in the meta data of the respective {\ttfamily spec}-\/keys, {\itshape override links} can be specified to use other keys in favor of the key itself. This way, even config from current folders ({\ttfamily dir}) can be overwritten.

In the cascading lookup, meta data of {\ttfamily spec}-\/keys comes in as follows\+:


\begin{DoxyEnumerate}
\item {\ttfamily override/\#} keys will be considered
\item namespaces specified in the {\ttfamily namespaces/\#} keys are considered
\item Otherwise, all namespaces will be considered, see \hyperlink{md_doc_help_elektra-namespaces_doc_help_elektra-namespaces_md}{here}.
\item {\ttfamily fallback/\#} keys will be considered
\item {\ttfamily default} value will be returned
\end{DoxyEnumerate}

{\bfseries Note\+:} {\ttfamily override/\#} means an array of {\ttfamily override} keys, the array can be filled by setting {\ttfamily \#} followed by the position, e.\+g. {\ttfamily \#0}, {\ttfamily \#1}, etc

As you can see, override links are considered before everything else, which makes them really powerful.

To create an override link, first you need to create a key to link the override to\+:

``` \$ sudo kdb set system/overrides/test \char`\"{}hello override\char`\"{} Create a new key system/overrides/test with string hello override ```

Override links can be defined by adding them to the {\ttfamily override/\#} array\+:

``` \$ sudo kdb setmeta spec/sw/tutorial/cascading/\#0/current/test override/\#0 /overrides/test \$ kdb get /sw/tutorial/cascading/\#0/current/test hello system override ```

Furthermore, you can specify a custom order for the namespaces, set fallback keys and more. For more information, read the \hyperlink{md_doc_help_elektra-spec_doc_help_elektra-spec_md}{`elektra-\/spec` help page}.

\subsection*{User defaults}

Override links can also be used to define default values. It's similar to defining default values via the {\ttfamily system} namespace, but uses overrides, which means it will be preferred over the configuration in the current folder ({\ttfamily dir}).

This means that user defaults overwrite values specified in the {\ttfamily .configuration} file we created and mounted earlier in this tutorial.

First you need to create the system default value to link the override to if the user hasn't defined it\+:

``` \$ sudo kdb set system/overrides/test \char`\"{}hello default\char`\"{} Create a new key system/overrides/test with string hello default ```

Then we can create the link\+:

``` \$ sudo kdb setmeta spec/sw/tutorial/cascading/\#0/current/test override/\#0 /overrides/test \$ kdb get /sw/tutorial/cascading/\#0/current/test hello default ```

Now the user overrides the system default\+:

``` \$ kdb set /overrides/test \char`\"{}hello user\char`\"{} Using name user/overrides/test Create a new key user/overrides/test with string hello user \$ kdb get /sw/tutorial/cascading/\#0/current/test hello user ``` 