\subsection*{Introduction}

The kdb tool allows users to interact with Elektra's Key Database via the command line. This tutorial explains the import function of kdb. This command lets you import Keys from the Elektra Key Database.

The command to use kdb import is\+: \begin{DoxyVerb}kdb import [options] destination [format]
\end{DoxyVerb}


In this command, destination is where the imported Keys should be stored below. For instance, {\ttfamily kdb import system/imported} would store all the keys below system/imported. This command takes Keys from stdin to store them into the Elektra Key Database. Typically, it is used with a pipe to read in the Keys from a file.

\subsubsection*{Format}

The format argument can be a very powerful option to use with kdb import. The format argument allows a user to specify which plug-\/in is used to import the Keys into the Key Database. The user can specify any storage plug-\/in to serve as the format for the Keys to be imported. For instance, if a user wanted to import a /etc/hosts file into K\+D\+B without mounting it, they could use the command {\ttfamily cat /etc/hosts $\vert$ kdb import system/hosts hosts}. This command would essentially copy the current hosts file into K\+D\+B, like mounting it. Unlike mounting it, changes to the Keys would not be reflected in the hosts file and vise versa.

\paragraph*{Dump Format}

If no format is specified, the format {\ttfamily dump} will be used instead. The dump format is the standard way of expressing Keys and all their relevant information. This format is intended to be used only within Elektra. The dump format is a good means of backing up Keys from the Key Database for use with Elektra later such as reimporting them later. As of this writing, dump is the only way to fully preserve all parts of the Key\+Set.

It is very important to note that the dump does not rename keys by design. If a user exports a Key\+Set using dump using a command such as {\ttfamily kdb export system/backup $>$ backup.\+ecf}, they can only import that keyset back into system/backup using a command like {\ttfamily cat backup.\+ecf $\vert$ kdb import system/backup}.

\subsection*{Options}

The kdb import command only takes one special option\+: \begin{DoxyVerb}    -s --strategy <name>            which is used to specify a strategy
\end{DoxyVerb}


\subsubsection*{Strategies}

For kdb import, you can specify a strategy to use if Keys already exist in the specified destination

The current list of strategies are\+:


\begin{DoxyItemize}
\item {\ttfamily preserve}\+: any keys already in the destination will not be overwritten
\item {\ttfamily overwrite}\+: any keys already in the destination will be overwritten if a new key has the same name
\item {\ttfamily cut}\+: all keys already in the destination will be removed, then new keys will be imported If no strategy is specified, the command defaults to the preserve strategy as to not be destructive to any previous keys.
\end{DoxyItemize}

\subsection*{Example}

\begin{DoxyVerb}    cat backup.ecf | kdb import system/backup
\end{DoxyVerb}


This command would import all keys stored in the file backup.\+ecf into the Key Database under system/backup.

In this example, backup.\+ecf was exported from the Key\+Set using the dump format by using the command\+: \begin{DoxyVerb}    kdb export system/backup > backup.ecf
\end{DoxyVerb}


backup.\+ecf contains all the information about the keys below system/backup\+: \begin{DoxyVerb}    $cat backup.ecf
    kdbOpen 1
    ksNew 3
    keyNew 19 0
    system/backup/key1
    keyMeta 7 1
    binary
    keyEnd
    keyNew 19 0
    system/backup/key2
    keyMeta 7 1
    binary
    keyEnd
    keyNew 19 0
    system/backup/key3
    keyMeta 7 1
    binary
    keyEnd
    ksEnd
\end{DoxyVerb}


Before the import command, system/backup does not exists and no keys are contained there. After the import command, running the command {\ttfamily kdb ls system/backup} prints\+: \begin{DoxyVerb}    system/backup/key1
    system/backup/key2
    system/backup/key3\end{DoxyVerb}
 