\subsection*{Issue}

When doing \hyperlink{group__kdb_ga28e385fd9cb7ccfe0b2f1ed2f62453a1}{kdb\+Get()} possible more keys are returned which might be confusing. When doing a second \hyperlink{group__kdb_ga28e385fd9cb7ccfe0b2f1ed2f62453a1}{kdb\+Get()} with a new keyset no keys might be returned, because it is up-\/to-\/date.

When doing \hyperlink{group__kdb_ga11436b058408f83d303ca5e996832bcf}{kdb\+Set()} a deep duplication is needed.

Idea\+: keep a duplicated keyset internally. Return (non-\/deep?) duplications exactly of the parts as requested.

\subsection*{Constraints}

\subsection*{Assumptions}

\subsection*{Considered Alternatives}


\begin{DoxyItemize}
\item no cache (current situation)
\item flat cache with C\+OW
\item deep duplicated cache
\end{DoxyItemize}

\subsection*{Decision}

Use global plugin to implement internal cache.

\subsection*{Argument}

Semantics can be provided without additional code or overhead in the core.

\subsection*{Implications}

\subsection*{Related decisions}

\subsection*{Notes}

internal caches lead to duplication of memory consumption (most of it is avoided by reference counting, though)

in some cases caches cannot be avoided? -\/$>$ filesys, databases?

cache discussion\+:
\begin{DoxyItemize}
\item not more keys than needed
\item kdb\+Get avoids IO even if done somewhere else
\item K\+DB handles could be more locally
\item not possible to access cache with current architecture, K\+DB high level A\+PI
\item implementation overhead
\item where should the caches be 
\end{DoxyItemize}