doc/elektra-api/man/man3/kdb.3

   1 .TH "KDB :: Low Level Methods" 3 "30 Jun 2009" "Elektra Projekt" \" -*- nroff -*-
   2 .ad l
   3 .nh
   4 .SH NAME
   5 KDB :: Low Level Methods \- General methods to access the Key database.
   6
   7 .PP
   8 .SS "Functions"
   9
  10 .in +1c
  11 .ti -1c
  12 .RI "int \fBkdbMount\fP (KDB *handle, const Key *mountpoint, const KeySet *config)"
  13 .br
  14 .ti -1c
  15 .RI "int \fBkdbUnmount\fP (KDB *handle, const Key *mountpoint)"
  16 .br
  17 .ti -1c
  18 .RI "Key * \fBkdbGetMountpoint\fP (KDB *handle, const Key *where)"
  19 .br
  20 .ti -1c
  21 .RI "KDB * \fBkdbOpen\fP ()"
  22 .br
  23 .ti -1c
  24 .RI "int \fBkdbClose\fP (KDB *handle)"
  25 .br
  26 .ti -1c
  27 .RI "ssize_t \fBkdbGet\fP (KDB *handle, KeySet *returned, Key *parentKey, option_t options)"
  28 .br
  29 .ti -1c
  30 .RI "ssize_t \fBkdbSet\fP (KDB *handle, KeySet *ks, Key *parentKey, option_t options)"
  31 .br
  32 .in -1c
  33 .SH "Detailed Description"
  34 .PP
  35 General methods to access the Key database.
  36 .PP
  37 To use them:
  38 .PP
  39 .nf
  40  #include <kdb.h>
  41
  42 .fi
  43 .PP
  44 .PP
  45 The kdb*() class of methods are used to access the storage, to get and set \fBKeys \fP or \fBKeySets \fP.
  46 .PP
  47 The most important functions are:
  48 .IP "\(bu" 2
  49 \fBkdbOpen()\fP
  50 .IP "\(bu" 2
  51 \fBkdbClose()\fP
  52 .IP "\(bu" 2
  53 \fBkdbGet()\fP
  54 .IP "\(bu" 2
  55 \fBkdbSet()\fP
  56 .PP
  57 .PP
  58 The two essential functions for dynamic information about backends are:
  59 .IP "\(bu" 2
  60 \fBkdbGetMountpoint()\fP
  61 .IP "\(bu" 2
  62 kdbGetCapability()
  63 .PP
  64 .PP
  65 They use some backend implementation to know the details about how to access the storage. Currently we have this backends:
  66 .IP "\(bu" 2
  67 \fCberkeleydb:\fP the keys are stored in a Berkeley DB database, providing very small footprint, speed, and other advantages.
  68 .IP "\(bu" 2
  69 \fCfilesys:\fP the key hierarchy and data are saved as plain text files in the filesystem.
  70 .IP "\(bu" 2
  71 \fCini:\fP the key hierarchy are saved into configuration files.
  72 .PP
  73 \fBSee also:\fP
  74 .RS 4
  75 http://www.libelektra.org/Ini
  76 .RE
  77 .PP
  78
  79 .IP "\(bu" 2
  80 \fCfstab:\fP a reference backend used to interpret the \fC/etc/fstab\fP file as a set of keys under \fCsystem/filesystems\fP .
  81 .IP "\(bu" 2
  82 \fCgconf:\fP makes Elektra use the GConf daemon to access keys. Only the \fCuser/\fP tree is available since GConf is not system wide.
  83 .PP
  84 .PP
  85 Backends are physically a library named \fC/lib/libelektra-{NAME}\fP.so.
  86 .PP
  87 See \fBwriting a new backend \fP for information about how to write a backend.
  88 .PP
  89 Language binding writers should follow the same rules:
  90 .IP "\(bu" 2
  91 You must relay completely on the backend-dependent methods.
  92 .IP "\(bu" 2
  93 You may use or reimplement the second set of methods.
  94 .IP "\(bu" 2
  95 You should completely reimplement in your language the higher lever methods.
  96 .IP "\(bu" 2
  97 Many methods are just for comfort in C. These methods are marked and need not to be implemented if the binding language has e.g. string operators which can do the operation easily.
  98 .PP
  99
 100 .SH "Function Documentation"
 101 .PP
 102 .SS "int kdbClose (KDB * handle)"
 103 .PP
 104 Closes the session with the Key database.
 105 .PP
 106 You should call this method when you finished your affairs with the key database. You can manipulate Key and KeySet objects also after \fBkdbClose()\fP. You must not use any kdb* call afterwards. You can implement \fBkdbClose()\fP in the atexit() handler.
 107 .PP
 108 This is the counterpart of \fBkdbOpen()\fP.
 109 .PP
 110 The \fChandle\fP parameter will be finalized and all resources associated to it will be freed. After a \fBkdbClose()\fP, this \fChandle\fP can't be used anymore, unless it gets initialized again with another call to \fBkdbOpen()\fP.
 111 .PP
 112 \fBSee also:\fP
 113 .RS 4
 114 \fBkdbOpen()\fP
 115 .RE
 116 .PP
 117 \fBParameters:\fP
 118 .RS 4
 119 \fIhandle\fP contains internal information of \fBopened \fP key database
 120 .RE
 121 .PP
 122 \fBReturns:\fP
 123 .RS 4
 124 0 on success
 125 .PP
 126 -1 on NULL pointer
 127 .RE
 128 .PP
 129
 130 .SS "ssize_t kdbGet (KDB * handle, KeySet * returned, Key * parentKey, option_t options)"
 131 .PP
 132 Retrieve keys in an atomic and universal way, all other kdbGet Functions rely on that one.
 133 .PP
 134 The \fCreturned\fP KeySet must be initialized or may already contain some keys. The new retrieved keys will be appended using \fBksAppendKey()\fP.
 135 .PP
 136 In default behaviour (\fCoptions\fP = 0) it will fully retrieve all keys under the \fCparentKey\fP folder, with all subfolders and their children but not inactive keys or folders.
 137 .PP
 138 The keyset will not be sorted at first place, but will be marked dirty and sorted afterwards when needed. That could be a subsequent \fBksLookup()\fP, \fBksLookupByName()\fP or \fBkdbSet()\fP. See \fBksSort()\fP on that issue.
 139 .PP
 140 The behaviour can be fine-tuned with options in various ways to make \fBkdbGet()\fP more comfortable.
 141 .SH "Options"
 142 .PP
 143 The \fCoption\fP is an array of the following ORed flags:
 144 .PP
 145 .IP "\(bu" 2
 146 \fCoption_t::KDB_O_DEL\fP
 147 .br
 148  Its often useful to \fBkeyDel()\fP the parentKey in the line after \fBkdbGet()\fP. Using this flag, you can just pass a key allocated with \fBkeyNew()\fP, \fBkdbGet()\fP will free it for you in the end.
 149 .IP "\(bu" 2
 150 \fCoption_t::KDB_O_POP\fP
 151 .br
 152  The \fCparentKey\fP itself will always be added to \fCreturned\fP. If you only want the children of the parentKey in \fCreturned\fP, but not the parentKey itself, use this flag. This is only valid for the first parentKey, the one you passed. The other recursive parentKeys will stay in the keyset. To get only the leaves of the tree, without any parentKey, see \fBoption_t::KDB_O_NODIR\fP below.
 153 .IP "\(bu" 2
 154 \fCoption_t::KDB_O_NODIR\fP
 155 .br
 156  Don't include folders in the \fCreturned\fP KeySet, so only keys without subkeys. You can picture it best that you only get the leaves of the tree of keys.
 157 .IP "\(bu" 2
 158 \fCoption_t::KDB_O_DIRONLY\fP
 159 .br
 160  Put in \fCreturned\fP only the folder keys. The resulting KeySet will be only the skeleton of the tree. This option must not be ORed together with KDB_O_DIR.
 161 .IP "\(bu" 2
 162 \fCoption_t::KDB_O_NOSTAT\fP
 163 .br
 164  Don't stat they keys, whatever \fBkeyNeedStat()\fP says. That means that also the key value and comment will be retrieved. The flag will result in that all keys in \fCreturned\fP don't have \fBkeyNeedStat()\fP set.
 165 .IP "\(bu" 2
 166 \fCoption_t::KDB_O_STATONLY\fP
 167 .br
 168  Only stat the keys. It means that key value and comment will not be retrieved. The resulting keys will contain only meta info such as user and group IDs, owner, mode permissions and modification times. You don't need that flag if the keys already have \fBkeyNeedStat()\fP set. The flag will result in that all keys in \fCreturned\fP have \fBkeyNeedStat()\fP set.
 169 .IP "\(bu" 2
 170 \fCoption_t::KDB_O_INACTIVE\fP
 171 .br
 172  Will make it not ignore inactive keys, so \fCreturned\fP will contain also inactive keys. Inactive keys are those that have names begining with '.' (dot). Please be sure that you know what you are doing, inactive keys must not have any semantics to the application. This flag should only be set in key browsers after explicit user request. You might also get inactive keys when you plan to remove a whole hierarchy.
 173 .IP "\(bu" 2
 174 \fCoption_t::KDB_O_SORT\fP
 175 .br
 176  Force \fCreturned\fP to be \fBksSort()\fPed. Normally you don't want that the \fCreturned\fP is sorted immediately because you might add other keys or go for another \fBkdbGet()\fP. Sorting will take place automatically when needed by \fBksLookup()\fP or \fBkdbSet()\fP, also without this option set. But you need to sort the keyset for yourself, when you just iterate over it. If you want to do that, pass this flag at the last \fBkdbGet()\fP.
 177 .IP "\(bu" 2
 178 \fCoption_t::KDB_O_NORECURSIVE\fP
 179 .br
 180  Dont get the keys recursive. Only receive keys from one folder. This might not work if the backend does not support it. Be prepared for more keys and use \fBksLookup()\fP and avoid static assumptions on how many keys you get.
 181 .PP
 182 .PP
 183 \fBExample:\fP.RS 4
 184
 185 .PP
 186 .nf
 187 KDB *handle;
 188 KeySet *myConfig;
 189 Key *key;
 190
 191 myConfig=ksNew(0);
 192
 193 handle = kdbOpen();
 194
 195 key=keyNew('system/sw/MyApp',KEY_END);
 196 rc=kdbGet(handle,key, myConfig, 0);
 197 keyDel(key);
 198
 199 key=keyNew('user/sw/MyApp',KEY_END);
 200 rc=kdbGet(handle,key, myConfig, 0);
 201 keyDel(key);
 202
 203 // will sort keyset here
 204 key=ksLookupByName(myConfig,'/sw/MyApp/key', 0);
 205 // check if key is not 0 and work with it...
 206
 207 ksDel (myConfig); // delete the in-memory configuration
 208
 209
 210 // maybe you want kdbSet() myConfig here
 211
 212 kdbClose(handle); // no more affairs with the key database.
 213
 214 .fi
 215 .PP
 216 .RE
 217 .PP
 218 .SH "Details"
 219 .PP
 220 When no backend could be found (e.g. no backend mounted) the default backend will be used.
 221 .PP
 222 If you pass a NULL pointer as handle and/or returned \fBkdbGet()\fP will return -1 and do nothing but \fBkeyDel()\fP the parentKey when requested and not a NULL pointer.
 223 .PP
 224 If you pass NULL as parentKey the root keys of all namespaces will be appended to returned.
 225 .PP
 226 For every directory key (\fBkeyIsDir()\fP) the appropriate backend will be chosen and keys in it will be requested.
 227 .PP
 228 If any backend reports an failure the recursive getting of keys will be stopped. Backends only report failure when they are not able to get keys for any problems.
 229 .PP
 230 \fBParameters:\fP
 231 .RS 4
 232 \fIhandle\fP contains internal information of \fBopened \fP key database
 233 .br
 234 \fIparentKey\fP parent key or NULL to get the root keys
 235 .br
 236 \fIreturned\fP the (pre-initialized) KeySet returned with all keys found
 237 .br
 238 \fIoptions\fP ORed options to control approaches
 239 .RE
 240 .PP
 241 \fBSee also:\fP
 242 .RS 4
 243 option_t
 244 .PP
 245 \fBkdb higher level Methods \fP that rely on \fBkdbGet()\fP
 246 .PP
 247 \fBksLookupByName()\fP, ksLookupByString() for powerful lookups after the KeySet was retrieved
 248 .PP
 249 commandList() code in \fBKDB :: Low Level Methods\fP command for usage example
 250 .PP
 251 commandEdit() code in \fBKDB :: Low Level Methods\fP command for usage example
 252 .PP
 253 commandExport() code in \fBKDB :: Low Level Methods\fP command for usage example
 254 .RE
 255 .PP
 256 \fBReturns:\fP
 257 .RS 4
 258 number of keys contained by \fCreturned\fP
 259 .PP
 260 -1 on failure
 261 .RE
 262 .PP
 263
 264 .SS "Key* kdbGetMountpoint (KDB * handle, const Key * where)"
 265 .PP
 266 Lookup a mountpoint in a handle for a specific key.
 267 .PP
 268 Will return a key representing the mountpoint or null if there is no appropriate mountpoint e.g. its the root mountpoint.
 269 .PP
 270 Together with kdbGetCapability() the two essential informations about mounted backends.
 271 .PP
 272 \fBExample:\fP.RS 4
 273
 274 .PP
 275 .nf
 276 Key * key = keyNew ('system/template');
 277 KDB * handle = kdbOpen();
 278 Key *mountpoint=0;
 279 mountpoint=kdbGetMountpoint(handle, key);
 280
 281 printf('The library I am using is %s mounted in %s\n',
 282         keyValue(mountpoint),
 283         keyName(mountpoint));
 284 kdbClose (handle);
 285 keyDel (key);
 286
 287 .fi
 288 .PP
 289 .RE
 290 .PP
 291 \fBParameters:\fP
 292 .RS 4
 293 \fIhandle\fP is the data structure, where the mounted directories are saved.
 294 .br
 295 \fIwhere\fP the key, that should be looked up.
 296 .RE
 297 .PP
 298 \fBReturns:\fP
 299 .RS 4
 300 the mountpoint associated with the key
 301 .RE
 302 .PP
 303
 304 .SS "int kdbMount (KDB * handle, const Key * mountpoint, const KeySet * config)"
 305 .PP
 306 Dynamically mount a single backend.
 307 .PP
 308 Maps the mountpoint, defined through its name and value, into the global elektra hierachy. If successfull, under the mountpoint another backend will reside.
 309 .PP
 310 This only works for a single KDB, that means a single thread in a single process. You may want statically mounting by editing system/elektra/mountpoints.
 311 .PP
 312 If you allocated mountpoint and config first, make sure that you free it! It is ok to free it immediately afterwards.
 313 .PP
 314 \fBParameters:\fP
 315 .RS 4
 316 \fIhandle\fP handle to the kdb data structure
 317 .br
 318 \fImountpoint\fP the \fBkeyName()\fP of this key is the mountpoint, \fBkeyValue()\fP the backend
 319 .br
 320 \fIconfig\fP the configuration passed for that backend
 321 .RE
 322 .PP
 323 \fBReturns:\fP
 324 .RS 4
 325 0 on success, -1 if an error occurred
 326 .RE
 327 .PP
 328
 329 .SS "KDB* kdbOpen (void)"
 330 .PP
 331 Opens the session with the Key database.
 332 .PP
 333 The first step is to open the default backend. With it system/elektra/mountpoints will be loaded and all needed libraries and mountpoints will be determined. These libraries for backends will be loaded and with it the \fCKDB\fP datastructure will be initialized.
 334 .PP
 335 You must always call this method before retrieving or commiting any keys to the database. In the end of the program, after using the key database, you must not forget to \fBkdbClose()\fP. You can use the atexit () handler for it.
 336 .PP
 337 The pointer to the \fCKDB\fP structure returned will be initialized like described above, and it must be passed along on any kdb*() method your application calls.
 338 .PP
 339 Get a \fCKDB\fP handle for every thread using elektra. Don't share the handle across threads, and also not the pointer accessing it:
 340 .PP
 341 .nf
 342 thread1 {
 343         KDB * h;
 344         h = kdbOpen();
 345         // fetch keys and work with them
 346         kdbClose(h);
 347 }
 348 thread2 {
 349         KDB * h;
 350         h = kdbOpen();
 351         // fetch keys and work with them
 352         kdbClose(h);
 353 }
 354
 355 .fi
 356 .PP
 357 .PP
 358 You don't need to use the \fBkdbOpen()\fP if you only want to manipulate plain in-memory Key or KeySet objects without any affairs with the backend key database,
 359 .PP
 360 \fBSee also:\fP
 361 .RS 4
 362 \fBkdbClose()\fP to end all affairs to the \fBKey :: Basic Methods\fP database.
 363 .RE
 364 .PP
 365 \fBReturns:\fP
 366 .RS 4
 367 a KDB pointer on success
 368 .PP
 369 NULL on failure
 370 .RE
 371 .PP
 372
 373 .SS "ssize_t kdbSet (KDB * handle, KeySet * ks, Key * parentKey, option_t options)"
 374 .PP
 375 Set keys in an atomic and universal way, all other kdbSet Functions rely on that one.
 376 .PP
 377 The given handle and keyset are the objects to work with.
 378 .PP
 379 With parentKey you can only store a part of the given keyset. Otherwise pass a null pointer or a parentKey without a name.
 380 .PP
 381 .PP
 382 .nf
 383 KeySet *ks = ksNew(0);
 384 kdbGet (h, ks, keyNew('system/myapp',0), KDB_O_DEL);
 385 kdbGet (h, ks, keyNew('user/myapp',0), KDB_O_DEL);
 386
 387 //now only set everything below user, because you can't write to system
 388 kdbSet (h, ks, keyNew('user/myapp',0), KDB_O_DEL);
 389
 390 ksDel (ks);
 391 .fi
 392 .PP
 393 .PP
 394 Each key is checked with \fBkeyNeedSync()\fP before being actually committed. So only changed keys are updated. If no key of a backend needs to be synced the \fBkdbSet_backend()\fP will be omitted.
 395 .PP
 396 If some error occurs, \fBkdbSet()\fP will stop. In this situation the KeySet internal cursor will be set on the key that generated the error. This specific key and all behind it were not set. To be failsafe jump over it and try to set the rest, but report the error to the user.
 397 .PP
 398 \fBExample of how this method can be used:\fP.RS 4
 399
 400 .PP
 401 .nf
 402 int i;
 403 KeySet *ks;  // the KeySet I want to set
 404 // fill ks with some keys
 405 for (i=0; i< 10; i++) // limit to 10 tries
 406 {
 407         ret=kdbSet(handle,ks, 0, 0);
 408         if (ret == -1)
 409         {
 410                 // We got an error. Warn user.
 411                 Key *problem;
 412                 problem=ksCurrent(ks);
 413                 if (problem)
 414                 {
 415                         char keyname[300]='';
 416                         keyGetFullName(problem,keyname,sizeof(keyname));
 417                         fprintf(stderr,'kdb import: while importing %s', keyname);
 418                 } else break;
 419                 // And try to set keys again starting from the next key,
 420                 // unless we reached the end of KeySet
 421                 if (ksNext(ks) == 0) break;
 422         }
 423 }
 424
 425 .fi
 426 .PP
 427 .RE
 428 .PP
 429 .SH "Options"
 430 .PP
 431 There are some options changing the behaviour of \fBkdbSet()\fP:
 432 .PP
 433 .IP "\(bu" 2
 434 \fCoption_t::KDB_O_DEL\fP
 435 .br
 436  Its often useful to \fBkeyDel()\fP the parentKey in the line after \fBkdbGet()\fP. Using this flag, you can just pass a key allocated with \fBkeyNew()\fP, \fBkdbGet()\fP will free it for you in the end.
 437 .IP "\(bu" 2
 438 \fCoption_t::KDB_O_SYNC\fP
 439 .br
 440  Will force to save all keys, independent of their sync state.
 441 .IP "\(bu" 2
 442 \fCoption_t::KDB_O_NOREMOVE\fP
 443 .br
 444  Don't remove any key from disk, even if \fBkeyRemove()\fP was set. With that flag removing keys can't happen unintentional. The flag will result in that all keys in \fCreturned\fP don't have \fBkeyNeedRemove()\fP set.
 445 .IP "\(bu" 2
 446 \fCoption_t::KDB_O_REMOVEONLY\fP
 447 .br
 448  Remove all keys instead of setting them. All keys in \fCreturned\fP will have \fBkeyNeedRemove()\fP set, but not \fBkeyNeedStat()\fP saying to you that the key was deleted permanently. This option implicit also activates \fCoption_t::KDB_O_SYNC\fP because the sync state will be changed when they are marked remove. You might need \fBoption_t::KDB_O_INACTIVE\fP set for the previous call of \fBkdbGet()\fP if there are any. Otherwise the recursive remove will fail, because removing directories is only possible when all subkeys are removed.
 449 .PP
 450 .SH "Details"
 451 .PP
 452 When you dont have a parentKey or its name empty, then all keys will be set.
 453 .PP
 454 You can remove some keys instead of setting them by marking them with \fBkeyRemove()\fP. The \fBkeyNeedSync()\fP flag will be unset after successful removing. But the \fBkeyNeedRemove()\fP flag will stay, but its safe to delete the key.
 455 .PP
 456 \fBParameters:\fP
 457 .RS 4
 458 \fIhandle\fP contains internal information of \fBopened \fP key database
 459 .br
 460 \fIks\fP a KeySet which should contain changed keys, otherwise nothing is done
 461 .br
 462 \fIparentKey\fP holds the information below which key keys should be set
 463 .br
 464 \fIoptions\fP see in \fBkdbSet()\fP documentation
 465 .RE
 466 .PP
 467 \fBReturns:\fP
 468 .RS 4
 469 0 on success
 470 .PP
 471 -1 on failure
 472 .RE
 473 .PP
 474 \fBSee also:\fP
 475 .RS 4
 476 \fBkeyNeedSync()\fP, \fBksNext()\fP, \fBksCurrent()\fP
 477 .PP
 478 \fBkeyRemove()\fP, \fBkeyNeedRemove()\fP
 479 .PP
 480 commandEdit(), commandImport() code in \fBKDB :: Low Level Methods\fP command for usage and error handling example
 481 .RE
 482 .PP
 483
 484 .SS "int kdbUnmount (KDB * handle, const Key * mountpoint)"
 485 .PP
 486 Dynamically unmount a single backend.
 487 .PP
 488 Unmount a backend that was mounted with \fBkdbMount()\fP before.
 489 .PP
 490 \fBParameters:\fP
 491 .RS 4
 492 \fIhandle\fP handle to the kdb data structure
 493 .br
 494 \fImountpoint\fP directory where backend is mounted to, that should be unmounted
 495 .RE
 496 .PP
 497 \fBReturns:\fP
 498 .RS 4
 499 0 on success, -1 if an error ocurred.
 500 .RE
 501 .PP
 502