Berkeley DB: DbInfo::set_flags
Description: Berkeley DB: An embedded database programmatic toolkit.
Keywords: embedded,database,programmatic,toolkit,b+tree,btr ee,hash,hashing,transaction,transactions,locking,logging,access method,access me thods,java,C,C++

# DbInfo::set_flags

`

###

    #include <db_cxx.h>

    void DbInfo::set_flags(u_int32_t);

# Description

The following additional flags may be specified for the Btree access method:

DB_DUP
  Permit duplicate data items in the tree, i.e. insertion when the key of the key/data pair being inserted already exists in the tree will be successful. The ordering of duplicates in the tree is determined by the order of insertion, unless the ordering is otherwise specified by use of a cursor or a duplicate comparison function. It is an error to specify both DB_DUP and DB_RECNUM.

DB_DUPSORT
  Sort duplicates within a set of data items. If the application does not specify a comparison function using the DbInfo::set_compare method, a default, lexical comparison will be used.

  Specifying that duplicates are to be sorted changes the behavior of the Db::put operation as well as the Dbc::put operation when the DB_KEYFIRST, DB_KEYLAST and DB_CURRENT flags are specified.

DB_RECNUM
  Support retrieval from btrees using record numbers. For more information, see the DB_GET_RECNO flag to the Db::get and Dbc::get methods.

  Logical record numbers in btrees 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 tree must be locked during both insertions and deletions, effectively single-threading the tree 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.

The following additional flags may be specified for the Hash access method:

DB_DUP
  Permit duplicate data items in the tree, i.e. insertion when the key of the key/data pair being inserted already exists in the tree will be successful. The ordering of duplicates in the tree is determined by the order of insertion, unless the ordering is otherwise specified by use of a cursor or a duplicate comparison function.

DB_DUPSORT
  Sort duplicates within a set of data items. If the application does not specify a comparison function using the DbInfo::set_compare method, a default, lexical comparison will be used.

  Specifying that duplicates are to be sorted changes the behavior of the Db::put operation as well as the Dbc::put operation when the DB_KEYFIRST, DB_KEYLAST and DB_CURRENT flags are specified.

The following additional flags may be specified for the Recno access method:

DB_DELIMITER
  The re_delim value has been set.

DB_FIXEDLEN
  The records are fixed-length, not byte delimited. The re_len value specifies the length of the record, and the re_pad value is used as the pad character.

  Any records added to the database that are less than re_len bytes long are automatically padded. Any attempt to insert records into the database that are greater than re_len bytes long will cause the call to fail immediately and return an error.

DB_PAD
  The re_pad field has been set.

DB_RENUMBER
  Specifying the DB_RENUMBER flag causes the logical record numbers to be mutable, and change as records are added to and deleted from the database. For example, the deletion of record number 4 causes records numbered 5 and greater to be renumbered downward by 1. If a cursor was positioned to record number 4 before the deletion, it will reference the new record number 4, if any such record exists, after the deletion. If a cursor was positioned after record number 4 before the deletion, it will be shifted downward 1 logical record, continuing to reference the same record as it did before.

  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 1. For example, the creation of a new record numbered 8 causes records numbered 8 and greater to be renumbered upward by 1. If a cursor was positioned to record number 8 or greater before the insertion, it will be shifted upward 1 logical record, continuing to reference 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.

DB_SNAPSHOT
  This flag specifies that any specified re_source file be read in its entirety when Db::open is called. If this flag is not specified, the re_source file may be read lazily.

# Class

DbInfo

# See Also

DbInfo::set_bt_compare, DbInfo::set_bt_maxkey, DbInfo::set_bt_minkey, DbInfo::set_bt_prefix, DbInfo::set_cachesize, DbInfo::set_compare, DbInfo::set_flags, DbInfo::set_h_ffactor, DbInfo::set_h_hash, DbInfo::set_h_nelem, DbInfo::set_lorder, DbInfo::set_malloc, DbInfo::set_pagesize, DbInfo::set_re_delim, DbInfo::set_re_len, DbInfo::set_re_pad and DbInfo::set_re_source.`