范德萨发而为
全部博文（392）
分类： 服务器与存储
2010-05-14 13:04:21
    |
#include
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);
The DB->associate() function
is used to declare one database a
secondary index for a primary database. The
DB handle that you call the
associate() method from is the
primary
database.
使用associate关联上主次数据库后，主数据库的数据更新将自动导致次数据库的索引更新
主数据库的key对次数据库来说必须是unique的，主数据库必须配置为不支持duplicate，这样是为了保证次数据库的key只对应一个主数据库中的记录？为什么不能对应多个呢？
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 in the Berkeley DB Programmer's Reference Guide for more information.
The DB->associate()
method returns a non-zero error value on failure and 0
on success.
The primary parameter should be a database handle for the primary database that is to be indexed.
If the operation is part of an
application-specified transaction, the
txnid
parameter is a transaction
handle returned from DB_ENV->txn_begin();
if the operation is part of a Berkeley DB
Concurrent Data Store group, the
txnid
parameter is a handle returned
from DB_ENV->cdsgroup_begin();
otherwise NULL. If no transaction handle is
specified, but the
operation occurs in a transactional database,
the operation will be
implicitly transaction protected.
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.
The callback parameter is a callback function that creates the set of secondary keys corresponding to 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 or keys.
Berkeley DB是不可重入的，回调函数中要避免使用不可重入的系统调用。
Berkeley DB is not re-entrant. Callback functions should not attempt to make library calls (for example, to release locks or close open handles). Re-entering Berkeley DB is not guaranteed to work correctly, and the results are undefined.
The result DBT can
have the following flags set in its
flags field:
需要将检索出的结果存储到DBT中，并且malloc其存储空间，使用此标志
DB_DBT_APPMALLOC
If the callback function needs to allocate memory for the result data field (rather than simply pointing into the primary key or datum), DB_DBT_APPMALLOC should be set in the flags field of the result DBT, which indicates that Berkeley DB should free the memory when it is done with it.
DB_DBT_MULTIPLE
To return multiple secondary keys, DB_DBT_MULTIPLE should be set in the flags field of the result DBT, which indicates Berkeley DB should treat the size field as the number of secondary keys (zero or more), and the data field as a pointer to an array of that number of DBTs describing the set of secondary keys.
When multiple secondary keys are returned, keys may not be repeated. In other words, there must be no repeated record numbers in the array for Recno and Queue databases, and keys must not compare equally using the secondary database's comparison function for Btree and Hash databases. If keys are repeated, operations may fail and the secondary may become inconsistent with the primary.
The DB_DBT_APPMALLOC flag may be set for any DBT in the array of returned DBT's to indicate that Berkeley DB should free the memory referenced by that particular DBT's data field when it is done with it.
The DB_DBT_APPMALLOC flag may be combined with DB_DBT_MULTIPLE in the result DBT's flag field to indicate that Berkeley DB should free the array once it is done with all of the returned keys.
In addition, the callback can optionally return the following special value:
DB_DONOTINDEX
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.
Returning DB_DONOTINDEX is equivalent to setting DB_DBT_MULTIPLE on the result DBT and setting the size field to zero.
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, the entire secondary index creation is performed in the context of a single transaction.
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
如果需要保证secondary keys不会改变，使用此标志。比如在primary数据库进行insert之后，为了保证secondary keys不会改变，使用此标志
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.
The DB->associate()
method may fail and return one of the following
non-zero errors:
When a client synchronizes with the master, it is
possible for committed
transactions to be rolled back. This invalidates all
the database and cursor
handles opened in the replication environment. Once this
occurs, an attempt to use
such a handle will
return DB_REP_HANDLE_DEAD.
The application will need to discard the handle and open
a new one in order to
continue processing.
The operation was blocked by client/master synchronization.
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.
