\label{doc_dev_classes_md_md_doc_dev_classes}%
\Hypertarget{doc_dev_classes_md_md_doc_dev_classes}%
 This overview complements the introduction in \href{https://doc.libelektra.org/api/latest/html/}{\texttt{ the API documentation}}.\hypertarget{doc_dev_classes_md_autotoc_md2245}{}\doxysection{Key}\label{doc_dev_classes_md_autotoc_md2245}
A {\ttfamily Key} consists of a name, a value and metadata. It is the atomic unit in the key database. Its main purpose is that it can be serialized to be written out to permanent storage. It can be added to several aggregates using reference counting. Putting {\ttfamily Key} objects into other data structures of supported programming languages presents no problem.\hypertarget{doc_dev_classes_md_autotoc_md2246}{}\doxysection{Key\+Set}\label{doc_dev_classes_md_autotoc_md2246}
The central data structure in Elektra is a {\ttfamily Key\+Set}. It aggregates {\ttfamily Key} objects in order to describe configuration in an easy but complete way. As the name \char`\"{}set\char`\"{} already implies every {\ttfamily Key} in a {\ttfamily Key\+Set} has a unique name. A user can iterate over the {\ttfamily Key} objects of a {\ttfamily Key\+Set}. {\ttfamily Key\+Set} sorts the keys by their names. This yields a deterministic order advantage. So, independent of the appending sequence and, in particular, the number of fetches and updates, {\ttfamily Key\+Set} guarantees the same order of the {\ttfamily Key} objects. Some configuration storage systems need this property, because they cannot remember a specific order. On the other hand, any particular order can easily be introduced (See \href{/home/jenkins/workspace/libelektra-release/doc/METADATA.ini}{\texttt{ order}}).

On the one side backends generate or store a {\ttfamily Key\+Set} object and, on the other side, elektrified applications receive and send a {\ttfamily Key\+Set} object. Both sides, as well as the core in between, have the possibility to iterate, update, modify, extend and reduce the key set. Appending of new or existing {\ttfamily Key} objects extends the key set. Otherwise it can be reduced if keys are popped out. The {\ttfamily Key} object becomes independent of the {\ttfamily Key\+Set} afterwards. The user can still change such a key or append it into another key set. The affiliation to a key set is not exclusive.

Every key in a {\ttfamily Key\+Set} object has a unique name. Appending {\ttfamily Key} objects with the same name will override the already existing {\ttfamily Key} object.\hypertarget{doc_dev_classes_md_autotoc_md2247}{}\doxysection{KDB}\label{doc_dev_classes_md_autotoc_md2247}
While objects of {\ttfamily Key} and {\ttfamily Key\+Set} only reside in memory, Elektra’s third class {\ttfamily KDB} actually provides access to the global key database. {\ttfamily KDB}, an abbreviation of key database, is responsible for actually storing and receiving configuration. {\ttfamily Key\+Set} represents the configuration when communicating with {\ttfamily KDB}. The typical elektrified application collects its configuration by one or many calls of {\ttfamily \mbox{\hyperlink{group__kdb_ga28e385fd9cb7ccfe0b2f1ed2f62453a1}{kdb\+Get()}}}. As soon as the program finishes its work with the {\ttfamily Key\+Set}, {\ttfamily \mbox{\hyperlink{group__kdb_ga11436b058408f83d303ca5e996832bcf}{kdb\+Set()}}} is in charge of writing all changes back to the key database.

This technique has some advantages. First, applications have full control over modifying {\ttfamily Key} and {\ttfamily Key\+Set} objects without touching the key database. Second, the decision how many {\ttfamily Key\+Set} objects the application administrates is left to the application. It can choose how to split up the {\ttfamily Key\+Set} objects. The main reason for this technique is that for backend development the same data structure is used, and as we will see, the borderline between application and backend development becomes blurred.

The application adapts the configuration between {\ttfamily \mbox{\hyperlink{group__kdb_ga28e385fd9cb7ccfe0b2f1ed2f62453a1}{kdb\+Get()}}} and {\ttfamily \mbox{\hyperlink{group__kdb_ga11436b058408f83d303ca5e996832bcf}{kdb\+Set()}}} in memory. The modifications are not only faster, they also allow large atomic configuration upgrades, robust merging of settings and handling of complicated inter-\/relationships between keys without problematic intermediate steps. Elektrified applications, however, should be aware of conflicts. It can happen that the key database is changed while working with a {\ttfamily Key\+Set}. Then, attempts to use {\ttfamily \mbox{\hyperlink{group__kdb_ga11436b058408f83d303ca5e996832bcf}{kdb\+Set()}}} lead to a conflict. {\ttfamily KDB} detects such situations gracefully and lets the application decide which configuration should be used.

For details and background \mbox{\hyperlink{doc_dev_data-structures_md}{read more about elektra data structures}}. For further information see \href{https://doc.libelektra.org/api/latest/html/}{\texttt{ the API documentation}}. 