Storage and retrieval for the Berkeley DB access methods are based on key/data pairs. Both key and data items are represented by the DBT data structure. (The name DBT is a mnemonic for data base thang, and was used because noone could think of a reasonable name that wasn't already in use somewhere else.)
typedef struct {
void *data; u_int32_t size; u_int32_t ulen; u_int32_t dlen; u_int32_t doff; u_int32_t flags;
} DBT;
Key and data byte strings may reference strings of essentially unlimited length. See Database limits for more information.
In order to ensure compatibility with future releases of Berkeley DB, all fields of the DBT structure that are not explicitly set should be initialized to 0 before the first time the structure is used. Do this by declaring the structure external or static, or by calling the C library routine bzero(3) or memset(3).
By default, the flags structure element is expected to be 0. In this default case, when being provided a key or data item by the application, the Berkeley DB package expects the data structure element to point to a byte string of size bytes. When returning a key/data item to the application, the Berkeley DB package will store into the data structure element a pointer to a byte string of size bytes.
The elements of the DBT structure are defined as follows:
Note that applications can determine the length of a record by setting
the ulen field to 0 and checking the return value in the
size field. See the DB_DBT_USERMEM flag for more information.
It is an error to specify both DB_DBT_MALLOC and DB_DBT_USERMEM.
For example, if the data portion of a retrieved record was 100 bytes,
and a partial retrieval was done using a DBT having a dlen
field of 20 and a doff field of 85, the get call would succeed,
the data field would reference the last 15 bytes of the record,
and the size field would be set to 15.
If the calling application is doing a put, the dlen bytes
starting doff bytes from the beginning of the specified key's
data record are replaced by the data specified by the data
and size structure elements.
If dlen is smaller than size, the record will grow,
and if dlen is larger than size, the record will shrink.
If the specified bytes do not exist, the record will be extended using
nul bytes as necessary, and the put call will succeed.
It is an error to attempt a partial put using the DB->get function
in a database that supports duplicate records.
Partial puts in databases supporting duplicate records must be done
using a DBcursor->c_put function.
It is an error to attempt a partial put with differing dlen and
size values in a recno database with fixed-length records.
For example, if the data portion of a retrieved record was 100 bytes,
and a partial put was done using a DBT having a dlen field of 20,
a doff field of 85, and a size field of 30, the resulting
record would be 115 bytes in length, where the last 30 bytes would be
those specified by the put call.
Retrieved key/data permanence: When using the non-cursor Berkeley DB calls to retrieve key/data items (e.g., DB->get), the memory referenced by the pointer stored into the DBT is only valid until the next call to Berkeley DB using the DB handle returned by db_open. (This includes any use of the returned DB handle, including by another thread of control within the process. For this reason, when multiple threads are using the returned DB handle concurrently, either the DB_DBT_MALLOC or DB_DBT_USERMEM flag must be specified for any non-cursor DBT used for key or data retrieval.) When using the cursor Berkeley DB calls to retrieve key/data items (e.g., DBcursor->c_get), the memory referenced by the pointer into the DBT is only valid until the next call to Berkeley DB using the DBC handle returned by DB->cursor.
The Berkeley DB access methods provide no guarantees about key/data byte string alignment, and applications are responsible for arranging any necessary alignment. The DB_DBT_MALLOC and DB_DBT_USERMEM flags may be used to store returned items in memory of arbitrary alignment.
Logical record numbers are 1-based, not 0-based, i.e., the first record in the database is record number 1.