An Embeddable Datastore Engine |
Tweet |
Follow @Vedis |
Vedis C/C++ API Reference - Datastore Handle.
Configure a datastore handle.
Description
This routine is used to configure a datastore handle obtained by a prior successful call to vedis_open().
The second argument to vedis_config() is an integer configuration option that determines what property of the datastore is to be configured. Subsequent arguments vary depending on the configuration option in the second argument. The default configuration is recommended for most applications and so this routine is usually not necessary. It is provided to support rare applications with unusual needs. Here is a list of allowed configuration options
Commands
|
Expected Arguments
|
Description
|
VEDIS_CONFIG_MAX_PAGE_CACHE | One Argument: int nMaxPage; |
Maximum raw pages to cache in memory. This is a simple hint, vedis is not forced to honor it. |
VEDIS_CONFIG_ERR_LOG | Two Arguments:
const char **pzPtr, int *pLen; |
The database error log is stored in an internal buffer. When something goes wrong during a commit, rollback, store, append operation, a human-readable error message is generated to help clients diagnostic the problem. This option can be used to point to that buffer. The first argument is a pointer address to a const char *. The second argument is an optional pointer to an integer. When set (i.e. not null), the integer value will hold the length of the error log in bytes. Example: if( rc != VEDIS_OK ){ const char *zBuf; int iLen; /* Something goes wrong, extract database error log */ vedis_config( pStore, VEDIS_CONFIG_ERR_LOG, &zBuf, &iLen ); if( iLen > 0 ){ puts(zBuf); } } |
VEDIS_CONFIG_KV_ENGINE | One Argument: const char *zKvName |
Switch to another Key/Value storage engine. This option is reserved for future usage. |
VEDIS_CONFIG_DISABE_AUTO_COMMIT | No Arguments |
Normally, If vedis_close() is invoked while a transaction is being active, the transaction is automatically committed. But, if this option is set, then the transaction is automatically rolled back and you should call vedis_commit() manually to commit all database changes. |
VEDIS_CONFIG_GET_KV_NAME | One Argument: const char **pzName; |
Extract the name of the underlying Key/Value storage engine (i.e. Hash, Mem, R+Tree, LSM, etc.). |
VEDIS_CONFIG_OUTPUT_CONSUMER |
Two Arguments: int (*xConsumer)( vedis_value *pOut, void *pUserData ), void *pUserData; |
This option is used to install a result output consumer callback. That is, an user defined function responsible of consuming the return value of the executed commands (i.e. GET, SET, HSET, etc.). This option accepts two arguments: The first argument is a pointer to the user defined function responsible of consuming the return value of the executed command. This callback must accept three arguments. The first argument is a pointer to the return value of the executed command and the last argument is an arbitrary user pointer forwarded verbatim by the engine to the callback as its last argument. Note: The engine will invoke this callback each time it have something to output. Refer to the implementation of the vedis Shell for an example of an output consumer callback. |
VEDIS_CONFIG_DUP_EXEC_VALUE | One Argument: vedis_value **ppOut; |
Duplicate the return value of the last executed vedis command. |
VEDIS_CONFIG_RELEASE_DUP_VALUE | One Argument: vedis_value *pIn; |
Release a previously duplicated vedis_value using VEDIS_CONFIG_DUP_EXEC_VALUE. |
Parameters
pStore |
Vedis datastore handle.
|
nOp
|
An integer configuration option that determines what property of the datastore is to be configured. |
Return value
See also