|
|
Db::set_flags |
#include <db_cxx.h>int Db::set_flags(u_int32_t flags);
int Db::get_flags(u_int32_t *flagsp);
Configure a database. Calling Db::set_flags is additive; there is no way to clear flags.
The Db::set_flags method may not be called after the Db::open method is called.
The Db::set_flags 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 following flags may be specified for any Berkeley DB access method:
Calling Db::set_flags with the DB_CHKSUM flag only affects the specified Db handle (and any other Berkeley DB handles opened within the scope of that handle).
If the database already exists when Db::open is called, the DB_CHKSUM flag will be ignored.
If creating additional databases in a file, the checksum behavior specified must be consistent with the existing databases in the file or an error will be returned.Calling Db::set_flags with the DB_ENCRYPT flag only affects the specified Db handle (and any other Berkeley DB handles opened within the scope of that handle).
If the database already exists when Db::open is called, the DB_ENCRYPT flag must be the same as the existing database or an error will be returned.
If creating additional databases in a file, the encryption behavior specified must be consistent with the existing databases in the file or an error will be returned.Encrypted databases are not portable between machines of different byte orders, that is, encrypted databases created on big-endian machines cannot be read on little-endian machines, and vice versa.
Calling Db::set_flags with the DB_TXN_NOT_DURABLE flag only affects the specified Db handle (and any other Berkeley DB handles opened within the scope of that handle).
The following flags may be specified for the Btree access method:
The DB_DUPSORT flag is preferred to DB_DUP for performance reasons. The DB_DUP flag should only be used by applications wanting to order duplicate data items manually.
Calling Db::set_flags with the DB_DUP flag affects the database, including all threads of control accessing the database.
If the database already exists when Db::open is called, the DB_DUP flag must be the same as the existing database or an error will be returned.
It is an error to specify both DB_DUP and DB_RECNUM.
Calling Db::set_flags with the DB_DUPSORT flag affects the database, including all threads of control accessing the database.
If the database already exists when Db::open is called, the DB_DUPSORT flag must be the same as the existing database or an error will be returned.
Logical record numbers in Btree databases are mutable in the face of record insertion or deletion. See the DB_RENUMBER flag in the Recno access method information for further discussion.
Maintaining record counts within a Btree introduces a serious point of contention, namely the page locations where the record counts are stored. In addition, the entire database must be locked during both insertions and deletions, effectively single-threading the database for those operations. Specifying DB_RECNUM can result in serious performance degradation for some applications and data sets.
It is an error to specify both DB_DUP and DB_RECNUM.
Calling Db::set_flags with the DB_RECNUM flag affects the database, including all threads of control accessing the database.
If the database already exists when Db::open is called, the DB_RECNUM flag must be the same as the existing database or an error will be returned.
Calling Db::set_flags with the DB_REVSPLITOFF flag only affects the specified Db handle (and any other Berkeley DB handles opened within the scope of that handle).
The following flags may be specified for the Hash access method:
The DB_DUPSORT flag is preferred to DB_DUP for performance reasons. The DB_DUP flag should only be used by applications wanting to order duplicate data items manually.
Calling Db::set_flags with the DB_DUP flag affects the database, including all threads of control accessing the database.
If the database already exists when Db::open is called, the DB_DUP flag must be the same as the existing database or an error will be returned.
Calling Db::set_flags with the DB_DUPSORT flag affects the database, including all threads of control accessing the database.
If the database already exists when Db::open is called, the DB_DUPSORT flag must be the same as the existing database or an error will be returned.
The following flags may be specified for the Queue access method:
The default behavior of queue databases is optimized for multiple readers, and does not guarantee that record will be retrieved in the order they are added to the queue. Specifically, if a writing thread adds multiple records to an empty queue, reading threads may skip some of the initial records when the next Db::get call returns.
This flag modifies the Db::get call to verify that the record being returned is in fact the head of the queue. This will increase contention and reduce concurrency when there are many reading threads.
Calling Db::set_flags with the DB_INORDER flag only affects the specified Db handle (and any other Berkeley DB handles opened within the scope of that handle).
The following flags may be specified for the Recno access method:
Using the Db::put or Dbc::put interfaces to create new records will cause the creation of multiple records if the record number is more than one greater than the largest record currently in the database. For example, creating record 28, when record 25 was previously the last record in the database, will create records 26 and 27 as well as 28. Attempts to retrieve records that were created in this manner will result in an error return of DB_KEYEMPTY.
If a created record is not at the end of the database, all records following the new record will be automatically renumbered upward by one. For example, the creation of a new record numbered 8 causes records numbered 8 and greater to be renumbered upward by one. If a cursor was positioned to record number 8 or greater before the insertion, it will be shifted upward one logical record, continuing to refer to the same record as it did before.
For these reasons, concurrent access to a Recno database with the DB_RENUMBER flag specified may be largely meaningless, although it is supported.
Calling Db::set_flags with the DB_RENUMBER flag affects the database, including all threads of control accessing the database.
If the database already exists when Db::open is called, the DB_RENUMBER flag must be the same as the existing database or an error will be returned.
Calling Db::set_flags with the DB_SNAPSHOT flag only affects the specified Db handle (and any other Berkeley DB handles opened within the scope of that handle).
The Db::set_flags method may fail and throw DbException, encapsulating one of the following non-zero errors, or return one of the following non-zero errors:
The Db::get_flags method returns the current flags.
The Db::get_flags method may be called at any time during the life of the application.
The Db::get_flags 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.
Copyright (c) 1996-2005 Sleepycat Software, Inc. - All rights reserved.