libdb/docs/api_reference/C/dbset_flags.html
2012-11-14 16:35:20 -05:00

592 lines
31 KiB
HTML
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>DB-&gt;set_flags()</title>
<link rel="stylesheet" href="apiReference.css" type="text/css" />
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
<link rel="start" href="index.html" title="Berkeley DB C API Reference" />
<link rel="up" href="db.html" title="Chapter 2.  The DB Handle" />
<link rel="prev" href="dbset_feedback.html" title="DB-&gt;set_feedback()" />
<link rel="next" href="dbset_h_compare.html" title="DB-&gt;set_h_compare()" />
</head>
<body>
<div xmlns="" class="navheader">
<div class="libver">
<p>Library Version 11.2.5.3</p>
</div>
<table width="100%" summary="Navigation header">
<tr>
<th colspan="3" align="center">DB-&gt;set_flags()</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="dbset_feedback.html">Prev</a> </td>
<th width="60%" align="center">Chapter 2. 
The DB Handle
</th>
<td width="20%" align="right"> <a accesskey="n" href="dbset_h_compare.html">Next</a></td>
</tr>
</table>
<hr />
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="dbset_flags"></a>DB-&gt;set_flags()</h2>
</div>
</div>
</div>
<pre class="programlisting">#include &lt;db.h&gt;
int
DB-&gt;set_flags(DB *db, u_int32_t flags); </pre>
<p>
Configure a database. Calling <code class="methodname">DB-&gt;set_flags()</code> is additive; there is
no way to clear flags.
</p>
<p>
The <code class="methodname">DB-&gt;set_flags()</code> method may not be called after the
<a class="xref" href="dbopen.html" title="DB-&gt;open()">DB-&gt;open()</a> method is called.
</p>
<p>
The <code class="methodname">DB-&gt;set_flags()</code> <span>
<span>
method returns a non-zero error value on failure and 0 on success.
</span>
</span>
</p>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="idp58289664"></a>Parameters</h3>
</div>
</div>
</div>
<div class="sect3" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="idp58291616"></a>flags</h4>
</div>
</div>
</div>
<p>
The <span class="bold"><strong>flags</strong></span> parameter must be set to 0
or by bitwise inclusively <span class="bold"><strong>OR</strong></span>'ing
together one or more of the following values:
</p>
<p>
<span class="bold"><strong>General</strong></span>
</p>
<p>
The following flags may be specified for any Berkeley DB access
method:
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><a id="dbset_flags_DB_CHKSUM"></a>
<code class="literal">DB_CHKSUM</code>
</p>
<p>
Do checksum verification of pages read into the cache from the backing
filestore. Berkeley DB uses the SHA1 Secure Hash Algorithm if
encryption is configured and a general hash algorithm if it is not.
</p>
<p>
Calling <code class="methodname">DB-&gt;set_flags()</code> with the DB_CHKSUM flag only affects the
specified <a class="link" href="db.html" title="Chapter 2.  The DB Handle">DB</a> handle (and
any other Berkeley DB handles opened within the scope of that handle).
</p>
<p>
If the database already exists when <a class="xref" href="dbopen.html" title="DB-&gt;open()">DB-&gt;open()</a>
is called, the DB_CHKSUM flag will be ignored.
</p>
</li>
<li>
<p><a id="dbset_flags_DB_ENCRYPT"></a>
<code class="literal">DB_ENCRYPT</code>
</p>
<p>
Encrypt the database using the cryptographic password specified to the
<a class="xref" href="envset_encrypt.html" title="DB_ENV-&gt;set_encrypt()">DB_ENV-&gt;set_encrypt()</a> or
<a class="xref" href="dbset_encrypt.html" title="DB-&gt;set_encrypt()">DB-&gt;set_encrypt()</a>
methods.
</p>
<p>
Calling <code class="methodname">DB-&gt;set_flags()</code> with the DB_ENCRYPT flag only affects the
specified <a class="link" href="db.html" title="Chapter 2.  The DB Handle">DB</a> handle (and
any other Berkeley DB handles opened within the scope of that handle).
</p>
<p>
If the database already exists when <a class="xref" href="dbopen.html" title="DB-&gt;open()">DB-&gt;open()</a>
is called, the DB_ENCRYPT flag must be the same as the existing database or an error
will be returned.
</p>
<p>
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.
</p>
</li>
<li>
<p><a id="dbset_flags_DB_TXN_NOT_DURABLE"></a>
<code class="literal">DB_TXN_NOT_DURABLE</code>
</p>
<p>
If set, Berkeley DB will not write log records for this database.
This means that updates of this database exhibit the ACI (atomicity,
consistency, and isolation) properties, but not D (durability); that
is, database integrity will be maintained, but if the application or
system fails, integrity will not persist. The database file must be
verified and/or restored from backup after a failure. In order to
ensure integrity after application shut down, the database handles
must be closed without specifying
<a class="link" href="dbclose.html#dbclose_DB_NOSYNC">DB_NOSYNC</a>, or all
database changes must be flushed from the database environment cache
using either the <a class="xref" href="txncheckpoint.html" title="DB_ENV-&gt;txn_checkpoint()">DB_ENV-&gt;txn_checkpoint()</a>
or <a class="xref" href="mempsync.html" title="DB_ENV-&gt;memp_sync()">DB_ENV-&gt;memp_sync()</a>
methods. All database handles for a single physical file must set
DB_TXN_NOT_DURABLE, including database handles for different databases
in a physical file.
</p>
<p>
Calling <code class="methodname">DB-&gt;set_flags()</code>
with the DB_TXN_NOT_DURABLE flag only affects the
specified <a class="link" href="db.html" title="Chapter 2.  The DB Handle">DB</a>
handle (and any other Berkeley DB handles opened
within the scope of that handle).
</p>
</li>
</ul>
</div>
<p>
<span class="bold"><strong>Btree</strong></span>
</p>
<p>
The following flags may be specified for the Btree access method:
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><a id="dbset_flags_DB_DUP"></a>
<code class="literal">DB_DUP</code>
</p>
<p>
Permit duplicate data items in the database; that is, insertion when
the key of the key/data pair being inserted already exists in the
database will be successful. The ordering of duplicates in the
database is determined by the order of insertion, unless the ordering
is otherwise specified by use of a cursor operation or a
duplicate sort function.
</p>
<p>
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.
</p>
<p>
Calling <code class="methodname">DB-&gt;set_flags()</code>
with the DB_DUP flag affects the database,
including all threads of control accessing the
database.
</p>
<p>
If the database already exists when
<a class="xref" href="dbopen.html" title="DB-&gt;open()">DB-&gt;open()</a>
is called, the DB_DUP flag must be the same as
the existing database or an error will be
returned.
</p>
<p>
It is an error to specify both DB_DUP and DB_RECNUM.
</p>
</li>
<li>
<p><a id="dbset_flags_DB_DUPSORT"></a>
<code class="literal">DB_DUPSORT</code>
</p>
<p>
Permit duplicate data items in the database; that is, insertion when
the key of the key/data pair being inserted already exists in the
database will be successful. The ordering of duplicates in the
database is determined by the duplicate comparison function. If the
application does not specify a comparison function using the
<a class="xref" href="dbset_dup_compare.html" title="DB-&gt;set_dup_compare()">DB-&gt;set_dup_compare()</a>
method, a default lexical comparison will be used. It is an error to
specify both DB_DUPSORT and DB_RECNUM.
</p>
<p>
Calling <code class="methodname">DB-&gt;set_flags()</code>
with the DB_DUPSORT flag affects the database,
including all threads of control accessing the
database.
</p>
<p>
If the database already exists when
<a class="xref" href="dbopen.html" title="DB-&gt;open()">DB-&gt;open()</a>
is called, the DB_DUPSORT flag must be the same
as the existing database or an error will be
returned.
</p>
</li>
<li>
<p><a id="dbset_flags_DB_RECNUM"></a>
<code class="literal">DB_RECNUM</code>
</p>
<p>
Support retrieval from the Btree using record numbers. For more
information, see the
<a class="link" href="dbget.html#dbget_DB_SET_RECNO">DB_SET_RECNO</a>
flag to the <a class="xref" href="dbget.html" title="DB-&gt;get()">DB-&gt;get()</a> and
<a class="xref" href="dbcget.html" title="DBcursor-&gt;get()">DBcursor-&gt;get()</a> methods.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
It is an error to specify both DB_DUP and DB_RECNUM.
</p>
<p>
Calling <code class="methodname">DB-&gt;set_flags()</code> with the DB_RECNUM flag affects the database,
including all threads of control accessing the database.
</p>
<p>
If the database already exists when <a class="xref" href="dbopen.html" title="DB-&gt;open()">DB-&gt;open()</a>
is called, the DB_RECNUM flag must be the same as the existing database or an error
will be returned.
</p>
</li>
<li>
<p><a id="dbset_flags_DB_REVSPLITOFF"></a>
<code class="literal">DB_REVSPLITOFF</code>
</p>
<p>
Turn off reverse splitting in the Btree. As pages are emptied in a
database, the Berkeley DB Btree implementation attempts to coalesce
empty pages into higher-level pages in order to keep the database as
small as possible and minimize search time. This can hurt performance
in applications with cyclical data demands; that is, applications
where the database grows and shrinks repeatedly. For example, because
Berkeley DB does page-level locking, the maximum level of concurrency
in a database of two pages is far smaller than that in a database of
100 pages, so a database that has shrunk to a minimal size can cause
severe deadlocking when a new cycle of data insertion begins.
</p>
<p>
Calling <code class="methodname">DB-&gt;set_flags()</code>
with the DB_REVSPLITOFF flag only affects the
specified <a class="link" href="db.html" title="Chapter 2.  The DB Handle">DB</a>
handle (and any other Berkeley DB handles opened
within the scope of that handle).
</p>
</li>
</ul>
</div>
<p>
<span class="bold"><strong>Hash</strong></span>
</p>
<p>
The following flags may be specified for the Hash access method:
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><a id="dbset_flags_h_DB_DUP"></a>
<code class="literal">DB_DUP</code>
</p>
<p>
Permit duplicate data items in the database; that is, insertion when
the key of the key/data pair being inserted already exists in the
database will be successful. The ordering of duplicates in the
database is determined by the order of insertion, unless the ordering
is otherwise specified by use of a cursor operation.
</p>
<p>
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.
</p>
<p>
Calling <code class="methodname">DB-&gt;set_flags()</code> with the DB_DUP flag affects the database,
including all threads of control accessing the database.
</p>
<p>
If the database already exists when <a class="xref" href="dbopen.html" title="DB-&gt;open()">DB-&gt;open()</a>
is called, the DB_DUP flag must be the same as the existing database or an error will be
returned.
</p>
</li>
<li>
<p>
<code class="literal">DB_DUPSORT</code>
</p>
<p>
Permit duplicate data items in the database; that is, insertion when
the key of the key/data pair being inserted already exists in the
database will be successful. The ordering of duplicates in the
database is determined by the duplicate comparison function. If the
application does not specify a comparison function using the
<a class="xref" href="dbset_dup_compare.html" title="DB-&gt;set_dup_compare()">DB-&gt;set_dup_compare()</a>
method, a default lexical comparison will be used.
</p>
<p>
Calling <code class="methodname">DB-&gt;set_flags()</code> with the DB_DUPSORT flag affects the
database, including all threads of control accessing the database.
</p>
<p>
If the database already exists when <a class="xref" href="dbopen.html" title="DB-&gt;open()">DB-&gt;open()</a>
is called, the DB_DUPSORT flag must be the same as the existing database or an error
will be returned.
</p>
</li>
<li>
<p><a id="dbset_flags_hash_DB_REVSPLITOFF"></a>
<code class="literal">DB_REVSPLITOFF</code>
</p>
<p>
Turns off hash bucket compaction. When a hash bucket is
emptied, the Berkeley DB Hash implementation will decrease
the hash table size, coalescing buckets. This will
decrease the number of pages in the database.
This can hurt performance in applications with cyclical
data demands — that is, applications where the
database grows and shrinks repeatedly — because of
the cost of resplitting buckets when they grow again.
</p>
<p>
Calling <code class="methodname">DB-&gt;set_flags()</code> with the
DB_REVSPLITOFF flag only affects the
specified <a class="link" href="db.html" title="Chapter 2.  The DB Handle">DB</a> handle (and
any other Berkeley DB handles opened within the scope of that handle).
</p>
</li>
</ul>
</div>
<p>
<span class="bold"><strong>Queue</strong></span>
</p>
<p>
The following flags may be specified for the Queue access method:
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>
<code class="literal">DB_INORDER</code>
</p>
<p>
The DB_INORDER flag modifies the operation of the
<a class="link" href="dbget.html#dbget_DB_CONSUME">DB_CONSUME</a> or
<a class="link" href="dbget.html#dbget_DB_CONSUME_WAIT">DB_CONSUME_WAIT</a>
flags to <a class="xref" href="dbget.html" title="DB-&gt;get()">DB-&gt;get()</a> to
return key/data pairs in order. That is, they will always return the
key/data item from the head of the queue.
</p>
<p>
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 <a class="xref" href="dbget.html" title="DB-&gt;get()">DB-&gt;get()</a>
call returns.
</p>
<p>
This flag modifies the <a class="xref" href="dbget.html" title="DB-&gt;get()">DB-&gt;get()</a>
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.
</p>
<p>
Calling <code class="methodname">DB-&gt;set_flags()</code> with the DB_INORDER flag only affects the
specified <a class="link" href="db.html" title="Chapter 2.  The DB Handle">DB</a> handle (and
any other Berkeley DB handles opened within the scope of that handle).
</p>
</li>
</ul>
</div>
<p>
<span class="bold"><strong>Recno</strong></span>
</p>
<p>
The following flags may be specified for the Recno access method:
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><a id="dbset_flags_DB_RENUMBER"></a>
<code class="literal">DB_RENUMBER</code>
</p>
<p>
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.
</p>
<p>
Using the <a class="xref" href="dbput.html" title="DB-&gt;put()">DB-&gt;put()</a> or
<a class="xref" href="dbcput.html" title="DBcursor-&gt;put()">DBcursor-&gt;put()</a> 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 <a href="../../programmer_reference/program_errorret.html#program_errorret.DB_KEYEMPTY" class="olink">DB_KEYEMPTY</a>.
</p>
<p>
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.
</p>
<p>
If a deleted record is not at the end of the database, all records
following the removed record will be automatically renumbered downward
by one. For example, deleting the record numbered 8 causes records
numbered 9 and greater to be renumbered downward by one. If a
cursor was positioned to record number 9 or greater before the
removal, it will be shifted downward one logical record, continuing to
refer to the same record as it did before.
</p>
<p>
If a record is deleted, all cursors that were positioned on that record
prior to the removal will no longer be positioned on a valid entry.
This includes cursors used to delete an item. For example, if
a cursor was positioned to record number 8 before the removal of
that record, subsequent calls to <a class="xref" href="dbcget.html" title="DBcursor-&gt;get()">DBcursor-&gt;get()</a>
with flags of DB_CURRENT will result in an error return of
<a href="../../programmer_reference/program_errorret.html#program_errorret.DB_KEYEMPTY" class="olink">DB_KEYEMPTY</a>
until the cursor is moved to another record. A call to
<a class="xref" href="dbcget.html" title="DBcursor-&gt;get()">DBcursor-&gt;get()</a> with flags of DB_NEXT
will return the new record numbered 8 - which is the record that was
numbered 9 prior to the delete (if such a record existed).
</p>
<p>
For these reasons, concurrent access to a Recno database with the
DB_RENUMBER flag specified may be largely meaningless, although it is
supported.
</p>
<p>
Calling <code class="methodname">DB-&gt;set_flags()</code> with the DB_RENUMBER flag affects the
database, including all threads of control accessing the database.
</p>
<p>
If the database already exists when <a class="xref" href="dbopen.html" title="DB-&gt;open()">DB-&gt;open()</a>
is called, the DB_RENUMBER flag must be the same as the existing database or an error
will be returned.
</p>
</li>
<li>
<p><a id="dbset_flags_DB_SNAPSHOT"></a>
<code class="literal">DB_SNAPSHOT</code>
</p>
<p>
This flag specifies that any specified <span class="bold"><strong>re_source</strong></span> file be read in its entirety when
<a class="xref" href="dbopen.html" title="DB-&gt;open()">DB-&gt;open()</a> is called. If
this flag is not specified, the <span class="bold"><strong>re_source</strong></span> file may be read lazily.
</p>
<p>
See the <a class="xref" href="dbset_re_source.html" title="DB-&gt;set_re_source()">DB-&gt;set_re_source()</a>
method for information on the <span class="bold"><strong>re_source</strong></span> file.
</p>
<p>
Calling <code class="methodname">DB-&gt;set_flags()</code> with the DB_SNAPSHOT flag only affects the
specified <a class="link" href="db.html" title="Chapter 2.  The DB Handle">DB</a> handle (and
any other Berkeley DB handles opened within the scope of that handle).
</p>
</li>
</ul>
</div>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="idp58291248"></a>Errors</h3>
</div>
</div>
</div>
<p>
The <code class="methodname">DB-&gt;set_flags()</code> <span>
<span>
method may fail and return one of the following non-zero errors:
</span>
</span>
</p>
<div class="sect3" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="idp58253608"></a>EINVAL</h4>
</div>
</div>
</div>
<p>
An invalid flag value or parameter was specified.
</p>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="idp58331968"></a>Class</h3>
</div>
</div>
</div>
<p>
<a class="link" href="db.html" title="Chapter 2.  The DB Handle">DB</a>
</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="idp58269456"></a>See Also</h3>
</div>
</div>
</div>
<p>
<a class="xref" href="db.html#dblist" title="Database and Related Methods">Database and Related Methods</a>
</p>
</div>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="dbset_feedback.html">Prev</a> </td>
<td width="20%" align="center">
<a accesskey="u" href="db.html">Up</a>
</td>
<td width="40%" align="right"> <a accesskey="n" href="dbset_h_compare.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">DB-&gt;set_feedback() </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> DB-&gt;set_h_compare()</td>
</tr>
</table>
</div>
</body>
</html>