NNAAMMEE DbInfo - informational parameters for database open SSYYNNOOPPSSIISS ##iinncclluuddee <> DDbbIInnffoo::::DDbbIInnffoo(());; DDbbIInnffoo::::~~DDbbIInnffoo(());; DDbbIInnffoo::::DDbbIInnffoo((ccoonnsstt DDbbIInnffoo &&));; DDbbIInnffoo::::DDbbIInnffoo &&ooppeerraattoorr == ((ccoonnsstt DDbbIInnffoo &&));; iinntt DDbbIInnffoo::::ggeett__lloorrddeerr(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__lloorrddeerr((iinntt));; ssiizzee__tt DDbbIInnffoo::::ggeett__ccaacchheessiizzee(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__ccaacchheessiizzee((ssiizzee__tt));; ssiizzee__tt DDbbIInnffoo::::ggeett__ppaaggeessiizzee(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__ppaaggeessiizzee((ssiizzee__tt));; ttyyppeeddeeff vvooiidd **((**ddbb__mmaalllloocc__ffccnn))((ssiizzee__tt));; DDbbIInnffoo::::ddbb__mmaalllloocc__ffccnn DDbbIInnffoo::::ggeett__mmaalllloocc(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__mmaalllloocc((ddbb__mmaalllloocc__ffccnn));; uu__iinntt3322__tt DDbbIInnffoo::::ggeett__bbtt__mmiinnkkeeyy(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__bbtt__mmiinnkkeeyy((uu__iinntt3322__tt));; ttyyppeeddeeff iinntt ((**bbtt__ccoommppaarree__ffccnn))((ccoonnsstt DDBBTT **,, ccoonnsstt DDBBTT **));; bbtt__ccoommppaarree__ffccnn DDbbIInnffoo::::ggeett__bbtt__ccoommppaarree(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__bbtt__ccoommppaarree((bbtt__ccoommppaarree__ffccnn));; ttyyppeeddeeff ssiizzee__tt ((**bbtt__pprreeffiixx__ffccnn))((ccoonnsstt DDBBTT **,, ccoonnsstt DDBBTT **));; bbtt__pprreeffiixx__ffccnn DDbbIInnffoo::::ggeett__bbtt__pprreeffiixx(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__bbtt__pprreeffiixx((bbtt__pprreeffiixx__ffccnn));; uu__iinntt3322__tt DDbbIInnffoo::::ggeett__hh__ffffaaccttoorr(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__hh__ffffaaccttoorr((uu__iinntt3322__tt));; uu__iinntt3322__tt DDbbIInnffoo::::ggeett__hh__nneelleemm(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__hh__nneelleemm((uu__iinntt3322__tt));; ttyyppeeddeeff uu__iinntt3322__tt ((**hh__hhaasshh__ffccnn))((ccoonnsstt vvooiidd **,, uu__iinntt3322__tt));; hh__hhaasshh__ffccnn DDbbIInnffoo::::ggeett__hh__hhaasshh(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__hh__hhaasshh((hh__hhaasshh__ffccnn));; iinntt DDbbIInnffoo::::ggeett__rree__ppaadd(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__rree__ppaadd((iinntt));; iinntt DDbbIInnffoo::::ggeett__rree__ddeelliimm(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__rree__ddeelliimm((iinntt));; uu__iinntt3322__tt DDbbIInnffoo::::ggeett__rree__lleenn(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__rree__lleenn((uu__iinntt3322__tt));; cchhaarr DDbbIInnffoo::::**ggeett__rree__ssoouurrccee(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__rree__ssoouurrccee((cchhaarr **));; uu__iinntt3322__tt DDbbIInnffoo::::ggeett__ffllaaggss(()) ccoonnsstt;; vvooiidd DDbbIInnffoo::::sseett__ffllaaggss((uu__iinntt3322__tt));; DDEESSCCRRIIPPTTIIOONN The DB library is a family of classes that provides a mod- ular programming interface to transactions and record-ori- ented file access. The library includes support for transactions, locking, logging and file page caching, as well as various indexed access methods. Many of the classes (e.g., the file page caching class) are useful independent of the other DB classes, although some classes are explicitly based on other classes (e.g., transactions and logging). For a general description of the DB pack- age, see _d_b___i_n_t_r_o(3). This manual page describes the DbInfo class. A DbInfo object is used in conjunction with the _D_b_:_:_o_p_e_n method (see _D_b(3)) to specify particular configuration options for the open. The DbInfo class provides simple access to an underlying data structure, whose elements can be exam- ined or changed using the _s_e_t__ or _g_e_t__ methods. The remainder of the manual page refers to these accesses using the underlying name, e.g., _c_a_c_h_e_s_i_z_e instead of _g_e_t___c_a_c_h_e_s_i_z_e and _s_e_t___c_a_c_h_e_s_i_z_e. The default constructor sets all elements of the underlying structure to zero. Some of the fields are specific to a type of file format (one of btree, hashed and recno) and are thus named with an underscore separated string, ``bt'', ``h'' and ``re'', respectively. For example, the method _s_e_t___b_t___m_i_n_k_e_y sets the underlying _b_t___m_i_n_k_e_y field, and this field is only used when opening a btree file. The fields that are common to all access methods are listed here; those specific to an individual access method are described below. No reference to the DbInfo object is maintained by Db, so it is possible to discard it as soon as the _D_b_:_:_o_p_e_n call returns. If possible, defaults appropriate for the system are used for the DbInfo fields if _d_b_i_n_f_o is NULL or any fields of the DbInfo object are not explicitly set. The following DbInfo fields may be initialized before calling _D_b_:_:_o_p_e_n: size_t cachesize; A suggested maximum size of the memory pool cache, in bytes. If _c_a_c_h_e_s_i_z_e is not explicitly set, an appro- priate default is used. It is an error to specify both the _m_p___i_n_f_o field and a non-zero _d_b___c_a_c_h_e_s_i_z_e. NNoottee,, tthhee mmiinniimmuumm nnuummbbeerr ooff ppaaggeess iinn tthhee ccaacchhee sshhoouulldd bbee nnoo lleessss tthhaann 1100,, aanndd tthhee aacccceessss mmeetthhooddss wwiillll ffaaiill iiff aann iinnssuuffffiicciieennttllyy llaarrggee ccaacchhee iiss ssppeecciiffiieedd.. In addition, for applications that exhibit strong local- ity in their data access patterns, increasing the size of the cache can significantly improve application performance. int lorder; The byte order for integers in the stored database metadata. The number should represent the order as an integer, for example, big endian order is the num- ber 4,321, and little endian order is the number 1,234. If _l_o_r_d_e_r is not explicitly set, the host order of the machine where the Db library was com- piled is used. The value of _l_o_r_d_e_r is ignored except when databases are being created. If a database already exists, the byte order it uses is determined when the file is read. TThhee aacccceessss mmeetthhooddss pprroovviiddee nnoo gguuaarraanntteeeess aabboouutt tthhee bbyyttee oorrddeerriinngg ooff tthhee aapppplliiccaattiioonn ddaattaa ssttoorreedd iinn tthhee ddaattaabbaassee,, aanndd aapppplliiccaattiioonnss aarree rreessppoonnssiibbllee ffoorr mmaaiinn-- ttaaiinniinngg aannyy nneecceessssaarryy oorrddeerriinngg.. size_t pagesize; The size of the pages used to hold items in the database, in bytes. The minimum page size is 512 bytes and the maximum page size is 64K bytes. If _p_a_g_e_s_i_z_e is not explicitly set, a page size is selected based on the underlying filesystem I/O block size. The selected size has a lower limit of 512 bytes and an upper limit of 16K bytes. void *(*malloc)(size_t); The flag DB_DBT_MALLOC, when specified in the Dbt object, will cause the Db library to allocate memory which then becomes the responsibility of the calling application. See _D_b_t(3) for more information. On systems where there may be multiple library ver- sions of malloc (notably Windows NT), specifying the DB_DBT_MALLOC flag will fail because the Db library will allocate memory from a different heap than the application will use to free it. To avoid this prob- lem, the _m_a_l_l_o_c function should be set to point to the application's allocation routine. If _m_a_l_l_o_c is not explicitly set, it will be used to allocate the memory returned when the DB_DBT_MALLOC flag is set. The _m_a_l_l_o_c method must match the calling conventions of the _m_a_l_l_o_c(3) library routine. BBTTRREEEE The btree data structure is a sorted, balanced tree struc- ture storing associated key/data pairs. Searches, inser- tions, and deletions in the btree will all complete in O (lg base N) where base is the average number of keys per page. Often, inserting ordered data into btrees results in pages that are half-full. This implementation has been modified to make ordered (or inverse ordered) insertion the best case, resulting in nearly perfect page space uti- lization. Space freed by deleting key/data pairs from the database is never reclaimed from the filesystem, although it is reused where possible. This means that the btree storage structure is grow-only. If sufficiently many keys are deleted from a tree that shrinking the underlying database file is desirable, this can be accomplished by creating a new tree from a scan of the existing one. The following additional fields and flags may be initial- ized in the DbInfo object before calling _D_b_:_:_o_p_e_n, when using the btree access method: int (*bt_compare)(const Dbt *, const Dbt *); The _b_t___c_o_m_p_a_r_e function is the key comparison method. It must return an integer less than, equal to, or greater than zero if the first key argument is con- sidered to be respectively less than, equal to, or greater than the second key argument. The same com- parison method must be used on a given tree every time it is opened. The _d_a_t_a and _s_i_z_e fields of the DBT are the only fields that may be used for the purposes of this com- parison. If _b_t___c_o_m_p_a_r_e is NULL, the keys are compared lexi- cally, with shorter keys collating before longer keys. u_int32_t bt_minkey; The minimum number of keys that will be stored on any single page. This value is used to determine which keys will be stored on overflow pages, i.e. if a key or data item is larger than the pagesize divided by the _b_t___m_i_n_k_e_y value, it will be stored on overflow pages instead of in the page itself. The _b_t___m_i_n_k_e_y value specified must be at least 2; if _b_t___m_i_n_k_e_y is not explicitly set, a value of 2 is used. size_t (*bt_prefix)(const Dbt *, const Dbt *); The _b_t___p_r_e_f_i_x function is the prefix comparison method. If specified, this method must return the number of bytes of the second key argument that are necessary to determine that it is greater than the first key argument. If the keys are equal, the key length should be returned. The _d_a_t_a and _s_i_z_e fields of the DBT are the only fields that may be used for the purposes of this comparison. This is used to compress the keys stored on the btree internal pages. The usefulness of this is data dependent, but in some data sets can produce signifi- cantly reduced tree sizes and search times. If _b_t___p_r_e_f_i_x is not explicitly set, and no comparison method is specified, a default lexical comparison method is used. If _b_t___p_r_e_f_i_x is NULL and a compari- son method is specified, no prefix comparison is done. unsigned long flags; The following additional flags may be specified: DB_DUP Permit duplicate keys in the tree, i.e. inser- tion when the key of the key/data pair being inserted already exists in the tree will be suc- cessful. 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 (see _D_b_c(3) for more information.) It is an error to specify both DB_DUP and DB_RECNUM. DB_RECNUM Support retrieval from btrees using record num- bers. For more information, see the DB_GET_RECNO flag to the _d_b_-_>_g_e_t method (below), and the cursor _D_b_c_:_:_g_e_t method (in _D_b_c(3)). Logical record numbers in btrees are mutable in the face of record insertion or deletion. See the DB_RENUMBER flag in the RECNO section below for further discussion. Maintaining record counts within a btree intro- duces 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 appli- cations and data sets. It is an error to specify both DB_DUP and DB_RECNUM. HHAASSHH The hash data structure is an extensible, dynamic hashing scheme. Backward compatible interfaces to the functions described in _d_b_m(3), _n_d_b_m(3) and _h_s_e_a_r_c_h(3) are provided, however these interfaces are not compatible with previous file formats. The following additional fields and flags may be initial- ized in the DbInfo object before calling _D_b_:_:_o_p_e_n, when using the hash access method: u_int32_t h_ffactor; The desired density within the hash table. It is an approximation of the number of keys allowed to accu- mulate in any one bucket, determining when the hash table grows or shrinks. The default value is 0, indicating that the fill factor will be selected dynamically as pages are filled. u_int32_t (*h_hash)(const void *, u_int32_t); The _h___h_a_s_h field is a user defined hash method; if _h___h_a_s_h is NULL, a default hash method is used. Since no hash method performs equally well on all possible data, the user may find that the built-in hash method performs poorly with a particular data set. User specified hash functions must take a pointer to a byte string and a length as arguments and return a u_int32_t value. If a hash method is specified, _h_a_s_h___o_p_e_n will attempt to determine if the hash method specified is the same as the one with which the database was created, and will fail if it detects that it is not. u_int32_t h_nelem; An estimate of the final size of the hash table. If not set or set too low, hash tables will expand gracefully as keys are entered, although a slight performance degradation may be noticed. The default value is 1. unsigned long flags; The following additional flags may be specified by oorr'ing together one or more of the following values: DB_DUP Permit duplicate keys in the tree, i.e. inser- tion when the key of the key/data pair being inserted already exists in the tree will be suc- cessful. 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 (see _D_b_c(3) for more information.) RREECCNNOO The recno access method provides support for fixed and variable length records, optionally backed by a flat text (byte stream) file. Both fixed and variable length records are accessed by their logical record number. It is valid to create a record whose record number is more than one greater than the last record currently in the database. For example, the creation of record number 8, when records 6 and 7 do not yet exist, is not an error. However, any attempt to retrieve such records (e.g., records 6 and 7) will return DB_KEYEMPTY. Deleting a record will not, by default, renumber records following the deleted record (see DB_RENUMBER below for more information). Any attempt to retrieve deleted records will return DB_KEYEMPTY. The following additional fields and flags may be initial- ized in the DbInfo object before calling _D_b_:_:_o_p_e_n, when using the recno access method: int re_delim; For variable length records, if the _r_e___s_o_u_r_c_e file is specified and the DB_DELIMITER flag is set, the delimiting byte used to mark the end of a record in the source file. If the _r_e___s_o_u_r_c_e file is specified and the DB_DELIMITER flag is not set, char- acters (i.e. ``\n'', 0x0a) are interpreted as end-of- record markers. u_int32_t re_len; The length of a fixed-length record. int re_pad; For fixed length records, if the DB_PAD flag is set, the pad character for short records. If the DB_PAD flag is not explicitly set, characters (i.e., 0x20) are used for padding. char *re_source; The purpose of the _r_e___s_o_u_r_c_e field is to provide fast access and modification to databases that are nor- mally stored as flat text files. If the _r_e___s_o_u_r_c_e field is explicitly set, it speci- fies an underlying flat text database file that is read to initialize a transient record number index. In the case of variable length records, the records are separated by the byte value _r_e___d_e_l_i_m. For exam- ple, standard UNIX byte stream files can be inter- preted as a sequence of variable length records sepa- rated by characters. In addition, when cached data would normally be writ- ten back to the underlying database file (e.g., the _c_l_o_s_e or _s_y_n_c functions are called), the in-memory copy of the database will be written back to the _r_e___s_o_u_r_c_e file. By default, the backing source file is read lazily, i.e., records are not read from the file until they are requested by the application. IIff mmuullttiippllee pprroo-- cceesssseess ((nnoott tthhrreeaaddss)) aarree aacccceessssiinngg aa rreeccnnoo ddaattaabbaassee ccoonnccuurrrreennttllyy aanndd eeiitthheerr iinnsseerrttiinngg oorr ddeelleettiinngg rreeccoorrddss,, tthhee bbaacckkiinngg ssoouurrccee ffiillee mmuusstt bbee rreeaadd iinn iittss eennttiirreettyy bbeeffoorree mmoorree tthhaann aa ssiinnggllee pprroocceessss aacccceesssseess tthhee ddaattaabbaassee,, aanndd oonnllyy tthhaatt pprroocceessss sshhoouulldd ssppeecciiffyy tthhee bbaacckkiinngg ssoouurrccee ffiillee aass ppaarrtt ooff tthhee _D_b_:_:_o_p_e_n call. See the DB_SNAPSHOT flag below for more information. RReeaaddiinngg aanndd wwrriittiinngg tthhee bbaacckkiinngg ssoouurrccee ffiillee ssppeecciiffiieedd bbyy rree__ssoouurrccee ccaannnnoott bbee ttrraannssaaccttiioonnaallllyy pprrootteecctteedd bbeeccaauussee iitt iinnvvoollvveess ffiilleessyysstteemm ooppeerraattiioonnss tthhaatt aarree nnoott ppaarrtt ooff tthhee DDbb ttrraannssaaccttiioonn mmeetthhooddoollooggyy.. For this reason, if a temporary database is used to hold the records, i.e., a NULL was specified as the _f_i_l_e argu- ment to _D_b_:_:_o_p_e_n, it is possible to lose the contents of the _r_e___s_o_u_r_c_e file, e.g., if the system crashes at the right instant. If a file is used to hold the database, i.e., a file name was specified as the _f_i_l_e argument to _D_b_:_:_o_p_e_n, normal database recovery on that file can be used to prevent information loss, although it is still possible that the contents of _r_e___s_o_u_r_c_e will be lost if the system crashes. The _r_e___s_o_u_r_c_e file must already exist (but may be zero-length) when _D_b_:_:_o_p_e_n is called. For all of the above reasons, the _r_e___s_o_u_r_c_e field is generally used to specify databases that are read- only for Db applications, and that are either gener- ated on the fly by software tools, or modified using a different mechanism, e.g., a text editor. unsigned long flags; The following additional flags may be specified by oorr'ing together one or more of the following values: DB_DELIMITER The _r_e___d_e_l_i_m field is set. DB_FIXEDLEN The records are fixed-length, not byte delim- ited. The _r_e___l_e_n value specifies the length of the record, and the _r_e___p_a_d value is used as the pad character. Any records added to the database that are less than _r_e___l_e_n bytes long are automatically padded. Any attempt to insert records into the database that are greater than _r_e___l_e_n bytes long will cause the call to fail immediately and return an error. DB_PAD The _r_e___p_a_d field is set. DB_RENUMBER Specifying the DB_RENUMBER flag causes the logi- cal 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 dele- tion, 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 _D_b_c_:_:_p_u_t or _p_u_t 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 num- bered 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 logi- cal 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 sup- ported. DB_SNAPSHOT This flag specifies that any specified _r_e___s_o_u_r_c_e file be read in its entirety when _D_b_:_:_o_p_e_n is called. If this flag is not specified, the _r_e___s_o_u_r_c_e file may be read lazily. SSEEEE AALLSSOO _d_b___a_r_c_h_i_v_e(1), _d_b___c_h_e_c_k_p_o_i_n_t(1), _d_b___d_e_a_d_l_o_c_k(1), _d_b___d_u_m_p(1), _d_b___l_o_a_d(1), _d_b___r_e_c_o_v_e_r(1), _d_b___s_t_a_t(1), _d_b___i_n_t_r_o(3), _d_b___i_n_t_e_r_n_a_l(3), _d_b___t_h_r_e_a_d(3), _D_b(3), _D_b_c(3), _D_b_E_n_v(3), _D_b_E_x_c_e_p_t_i_o_n(3), _D_b_I_n_f_o(3), _D_b_L_o_c_k(3), _D_b_L_o_c_k_T_a_b(3), _D_b_L_o_g(3), _D_b_L_s_n(3), _D_b_M_p_o_o_l(3), _D_b_M_p_o_o_l_F_i_l_e(3), _D_b_t(3), _D_b_T_x_n(3), _D_b_T_x_n_M_g_r(3)