#include <db_cxx.h> int Db::join(Dbc **curslist, Dbc **dbcp, u_int32_t flags);
The Db::join() method creates a specialized join cursor for use in
performing equality or natural joins on secondary indices. For
information on how to organize your data to use this functionality,
see Equality join.
The Db::join() method is called using the
Db handle of the primary
database.
The join cursor supports only the Dbc::get() and Dbc::close() cursor functions:
Iterates over the values associated with the keys to which each item in curslist was initialized. Any data value that appears in all items specified by the curslist parameter is then used as a key into the primary, and the key/data pair found in the primary is returned. The flags parameter must be set to 0 or the following value:
DB_JOIN_ITEM
Do not use the data value found in all the cursors as a lookup key for the primary, but simply return it in the key parameter instead. The data parameter is left unchanged.
In addition, the following flag may be set by bitwise inclusively OR'ing it into the flags parameter:
DB_READ_UNCOMMITTED
Configure a transactional join operation to have degree 1 isolation, reading modified but not yet committed data. Silently ignored if the DB_READ_UNCOMMITTED flag was not specified when the underlying database was opened.
DB_RMW
Acquire write locks instead of read locks when doing the read, if locking is configured. Setting this flag can eliminate deadlock during a read-modify-write cycle by acquiring the write lock during the read part of the cycle so that another thread of control acquiring a read lock for the same item, in its own read-modify-write cycle, will not result in deadlock.
Close the returned cursor and release all resources. (Closing the cursors in curslist is the responsibility of the caller.)
The Db::join()
method either returns a non-zero error value or throws an
exception that encapsulates a non-zero error value on
failure, and returns 0 on success.
The curslist parameter contains a NULL terminated array of cursors. Each cursor must have been initialized to refer to the key on which the underlying database should be joined. Typically, this initialization is done by a Dbc::get() call with the DB_SET flag specified. Once the cursors have been passed as part of a curslist, they should not be accessed or modified until the newly created join cursor has been closed, or else inconsistent results may be returned.
Joined values are retrieved by doing a sequential iteration over the
first cursor in the curslist
parameter, and a nested iteration over each secondary cursor in the
order they are specified in the curslist parameter. This requires database
traversals to search for the current datum in all the cursors after
the first. For this reason, the best join performance normally
results from sorting the cursors from the one that refers to the least
number of data items to the one that refers to the most. By default,
Db::join() does this sort on behalf of its caller.
For the returned join cursor to be used in a transaction-protected manner, the cursors listed in curslist must have been created within the context of the same transaction.
The flags parameter must be set to 0 or the following value:
Do not sort the cursors based on the number of data items to which
they refer. If the data are structured so that cursors with many data
items also share many common elements, higher performance will result
from listing those cursors before cursors with fewer data items; that
is, a sort order other than the default. The DB_JOIN_NOSORT flag
permits applications to perform join optimization prior to calling the
Db::join() method.
The Db::join()
method may fail and throw a DbException
exception, encapsulating one of the following non-zero errors, or 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
throw a DbRepHandleDeadException (if
your application is configured to throw exceptions), or
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.
DbDeadlockException is thrown if
your Berkeley DB API is configured to throw exceptions.
Otherwise, DB_REP_LOCKOUT is returned.
If cursor methods other than Dbc::get() or Dbc::close() were called; or if an invalid flag value or parameter was specified.