summaryrefslogtreecommitdiff
path: root/src/docs/cursor-log.dox
diff options
context:
space:
mode:
Diffstat (limited to 'src/docs/cursor-log.dox')
-rw-r--r--src/docs/cursor-log.dox30
1 files changed, 21 insertions, 9 deletions
diff --git a/src/docs/cursor-log.dox b/src/docs/cursor-log.dox
index 81e98203c39..fd247dd7105 100644
--- a/src/docs/cursor-log.dox
+++ b/src/docs/cursor-log.dox
@@ -1,4 +1,4 @@
-/*! @page cursor_log Log cursors
+/*! @m_page{{c,java},cursor_log,Log cursors}
WiredTiger cursors provide access to data from a variety of sources, and
one of these sources is the records in the transaction log files. Log
@@ -22,7 +22,12 @@ To open a log cursor on the database:
@snippet ex_log.c log cursor open
-A log cursor's key is a unique log record identifier, plus a uint32_t
+A log cursor's key is a unique log record identifier, plus a
+@m_if{c}
+uint32_t
+@m_else
+int
+@m_endif
operation counter within that log record. When a log record maps
one-to-one to a transaction (in other words, the returned log record has
the only database operation the transaction made), the operation counter
@@ -38,10 +43,17 @@ Here is an example of getting the log cursor's key:
The log cursor's value is comprised of six fields:
-- a uint64_t transaction ID (set for commit records only, otherwise 0),
-- a uint32_t record type
-- a uint32_t operation type (set for commit records only, otherwise 0)
-- a uint32_t file id (if applicable, otherwise 0)
+@m_if{c}
+- a \c uint64_t transaction ID (set for commit records only, otherwise 0),
+- a \c uint32_t record type
+- a \c uint32_t operation type (set for commit records only, otherwise 0)
+- a \c uint32_t file id (if applicable, otherwise 0)
+@m_else
+- a \c long transaction ID (set for commit records only, otherwise 0),
+- a \c int record type
+- a \c int operation type (set for commit records only, otherwise 0)
+- a \c int file id (if applicable, otherwise 0)
+@m_endif
- the operation key (commit records only, otherwise empty)
- the operation value
@@ -49,9 +61,9 @@ The transaction ID may not be unique across recovery, that is, closing
and reopening the database may result in transaction IDs smaller than
previously seen transaction IDs.
-The record and operation types are taken from @ref log_types; typically,
-the only record or operation type applications are concerned with is
-::WT_LOGREC_MESSAGE, which is a log record generated by the application.
+The record and operation types are taken from @ref_single log_types;
+typically, the only record or operation type applications are concerned with
+is ::WT_LOGREC_MESSAGE, which is a log record generated by the application.
The file ID may not be unique across recovery, that is, closing and
reopening the database may result in file IDs changing. Additionally,