.TH "doc_help_elektra-granularity_md" 3elektra "Sun May 29 2016" "Version 0.8.14" "Elektra" \" -*- nroff -*-
.ad l
.nh
.SH NAME
doc_help_elektra-granularity_md \- elektra-granularity\&.md 

.SH "elektra-granularity(7) -- relation of keys to files "
.PP
.PP
Keys of a backend can only be retrieved as a full key set\&. Currently it is not possible to fetch a part of the keys of a backend\&. So the user needs to cut out the interesting keys with \fC\fBksCut()\fP\fP afterwards\&. If the keys should be committed again, the whole key set must be preserved\&. Otherwise, the clipped keys will be removed permanently\&.
.PP
This restriction simplifies storage plugins while it does not limit the user\&. Other plugins would not be able to fulfil their purpose without the full \fCKeySet\fP\&. For example, a plugin that checks the availability and structure of all keys cannot work with a partial key set\&.
.PP
It is problematic to have too many keys in one backend\&. The applications would need memory for unnecessary configuration data\&. Instead we recommend introducing several mount points to split up the keys into different backends\&. Splitting up key sets makes sense if any application requests only a part of the configuration\&. No benefits arise if every application requests all keys anyway\&.
.PP
Let us assume that many keys reside in \fCuser/sw\fP and an application only needs the keys in \fCuser/sw/app\fP\&. To save memory and get better startup times for the application, a new backend can be mounted at \fCuser/sw/app\fP\&. On the other hand, every mounted backend causes a small run time overhead in the overall configuration system\&.
.PP
The solution in Elektra is flexible, because the user decides the granularity\&. It is possible to mount a backend on every single key, so that every key can be requested for itself\&. If no backends are mounted, all keys reside in the default backend\&.
.PP
To sum up, Elektra's core searches for the nearest mount point and gets the configuration from there\&. It is possible that the user gets more configuration than requested\&. The user can decide by means of mounting how much configuration on specific requests are returned\&.