.TH "md_doc_help_elektra-plugins-ordering" 3elektra "Sun May 29 2016" "Version 0.8.14" "Elektra" \" -*- nroff -*-
.ad l
.nh
.SH NAME
md_doc_help_elektra-plugins-ordering \- elektra-plugins-ordering(7) -- ordering of plugins 
You should first read \fBelektra-plugins(7)\fP to get an idea about plugins\&.
.PP
This document describes how \fBelektra-plugins(7)\fP are ordered with an \fBelektra-backend(7)\fP\&.
.PP
Multiple plugins open up many ways in which they can be arranged\&. A simple way is to have one array with pointers to plugins\&. To store a \fCKeySet\fP, the first plugin starts off with the \fCKeySet\fP passed to it\&. The resulting \fCKeySet\fP is given to the next plugin\&. This is repeated for every plugin in the array\&.
.PP
To obtain a \fCKeySet\fP, the array of plugins is processed the other way round\&. An empty \fCKeySet\fP is passed to the last plugin\&. The resulting \fCKeySet\fP is handed over to the previous one until the first plugin is executed\&.
.PP
This approach has shown not to be powerful enough to express all use cases by counter-evidence\&. Logging should take place after the storage plugin performs its actions in both directions\&. It is not possible to do this with a \fIsingle array\fP processed in a way as described above\&.
.PP
Two individual lists (get+set list) of plugins solve the described problem\&. Instead of bidirectional processing of a single list two separate arrays are used\&. It turns out that error scenarios also make this approach unsuccessful\&. When a plugin fails, no other plugin must be executed later on because it might depend on the previous plugin to work correctly\&. In \fC\fBkdbGet()\fP\fP, this works well -- the update process will be stopped\&. But during \fC\fBkdbSet()\fP\fP, changes to the file system must be reverted\&. Plugins can leave a lock, temporary file or journal\&. These resources need to be cleaned up properly\&.
.PP
.SS "Error List"
.PP
So every backend additionally needs a third array that is executed in error scenarios during \fC\fBkdbSet()\fP\fP\&. Plugins responsible for the cleanup, rollback or error notification are inserted into it\&.
.PP
The resolver plugin requires this error list to do a proper rollback\&. Another use case is logging after a failure has happened\&.
.PP
.SS "Placements"
.PP
The ordering of plugins inside these three arrays is controlled by \fBelektra-contracts(7)\fP\&. Each of the three arrays has ten slots\&. These slots have names to be referred to in the contract\&.
.PP
Here you see a table that contains all names: 
.PP
.nf
    0     prerollback       getresolver         setresolver  
    1     prerollback       pregetstorage      presetstorage 
    2     prerollback       pregetstorage      presetstorage 
    3     prerollback       pregetstorage      presetstorage 
    4     prerollback       pregetstorage      presetstorage 
    5      rollback            getstorage         setstorage 
    6    postrollback      postgetstorage      precommit     
    7    postrollback      postgetstorage         commit     
    8    postrollback      postgetstorage     postcommit     
    9    postrollback      postgetstorage     postcommit     

.fi
.PP
.PP
how the placement is influenced using infos/placement, infos/ordering and infos/stacking as described in \fBCONTRACT\&.ini\fP\&.