#include <db.h>

int
DB->associate(DB *primary, DB_TXN *txnid, DB *secondary,
    int (*callback)(DB *secondary,
    const DBT *key, const DBT *data, DBT *result), u_int32_t flags);

Description: DB->associate

The DB->associate function is used to declare one database a secondary index for a primary database. After a secondary database has been "associated" with a primary database, all updates to the primary will be automatically reflected in the secondary and all reads from the secondary will return corresponding data from the primary. Note that as primary keys must be unique for secondary indices to work, the primary database must be configured without support for duplicate data items. See Secondary indices for more information.

The DB->associate method returns a non-zero error value on failure and 0 on success.

Parameters

callback

The callback parameter is a callback function that creates a secondary key from a given primary key and data pair.

The callback parameter may be NULL if both the primary and secondary database handles were opened with the DB_RDONLY flag.

The callback takes four arguments:

secondary

The secondary parameter is the database handle for the secondary.

key

The key parameter is a DBT referencing the primary key.

data

The data parameter is a DBT referencing the primary data item.

result

The result parameter is a zeroed DBT in which the callback function should fill in data and size fields that describe the secondary key.

If the callback function needs to allocate memory for the data field rather than simply pointing into the primary key or datum, the flags field of the returned DBT should be set to DB_DBT_APPMALLOC, which indicates that Berkeley DB should free the memory when it is done with it.

If any key/data pair in the primary yields a null secondary key and should be left out of the secondary index, the callback function may optionally return DB_DONOTINDEX. Otherwise, the callback function should return 0 in case of success or an error outside of the Berkeley DB name space in case of failure; the error code will be returned from the Berkeley DB call that initiated the callback.

If the callback function returns DB_DONOTINDEX for any key/data pairs in the primary database, the secondary index will not contain any reference to those key/data pairs, and such operations as cursor iterations and range queries will reflect only the corresponding subset of the database. If this is not desirable, the application should ensure that the callback function is well-defined for all possible values and never returns DB_DONOTINDEX.

flags

The flags parameter must be set to 0 or by bitwise inclusively OR'ing together one or more of the following values:

DB_CREATE

If the secondary database is empty, walk through the primary and create an index to it in the empty secondary. This operation is potentially very expensive.

If the secondary database has been opened in an environment configured with transactions, each put necessary for its creation will be done in the context of a transaction created for the purpose.

Care should be taken not to use a newly-populated secondary database in another thread of control until the DB->associate call has returned successfully in the first thread.

If transactions are not being used, care should be taken not to modify a primary database being used to populate a secondary database, in another thread of control, until the DB->associate call has returned successfully in the first thread. If transactions are being used, Berkeley DB will perform appropriate locking and the application need not do any special operation ordering.

DB_IMMUTABLE_KEY

Specifies the secondary key is immutable.

This flag can be used to optimize updates when the secondary key in a primary record will never be changed after the primary record is inserted. For immutable secondary keys, a best effort is made to avoid calling the secondary callback function when primary records are updated. This optimization may reduce the overhead of update operations significantly if the callback function is expensive.

Be sure to specify this flag only if the secondary key in the primary record is never changed. If this rule is violated, the secondary index will become corrupted, that is, it will become out of sync with the primary.

primary

The primary parameter should be a database handle for the primary database that is to be indexed.

secondary

The secondary parameter should be an open database handle of either a newly created and empty database that is to be used to store a secondary index, or of a database that was previously associated with the same primary and contains a secondary index. Note that it is not safe to associate as a secondary database a handle that is in use by another thread of control or has open cursors. If the handle was opened with the DB_THREAD flag it is safe to use it in multiple threads of control after the DB->associate method has returned. Note also that either secondary keys must be unique or the secondary database must be configured with support for duplicate data items.

txnid

If the operation is part of an application-specified transaction, the txnid parameter is a transaction handle returned from DB_ENV->txn_begin; otherwise NULL. If no transaction handle is specified, but the operation occurs in a transactional database, the operation will be implicitly transaction protected.

Errors

The DB->associate method may fail and return one of the following non-zero errors:

DB_REP_HANDLE_DEAD

The database handle has been invalidated because a replication election unrolled a committed transaction.

DB_REP_LOCKOUT

The operation was blocked by client/master synchronization.

EINVAL

If the secondary database handle has already been associated with this or another database handle; the secondary database handle is not open; the primary database has been configured to allow duplicates; or if an invalid flag value or parameter was specified.

Class

See Also