meta: stubs and index reference clean up

Author: Sam Kleinman

source/applications.rst

@@ -9,6 +9,7 @@ Application Development
    :maxdepth: 3
 
    applications/schema-design
+   applications/simple-aggregation
    core/map-reduce
    applications/optimization
    applications/drivers

source/applications/simple-aggregation.rst

@@ -0,0 +1,3 @@
+=============================
+Simple Aggregation Operations
+=============================

source/contents.rst

@@ -10,7 +10,7 @@ MongoDB Manual Contents
    sharding
    administration
    applications
-   core/indexes
+   core/indexing
    mongo
    reference
 

source/core/indexes.rst renamed to source/core/indexing.rst

@@ -554,9 +554,9 @@ accepted write operations that have replicated to the
 rare and typically occurs as a result of a network partition with
 replication lag. When this node (the former primary) rejoins the
 :term:`replica set` and attempts to continue replication as a
-secondary those operations that were not replicated have to be
-removed, or "rolled back," to maintain database consistency across the
-replica set.
+secondary those operations the former primary must revert these
+operations or "rolled back" these operations to maintain database
+consistency across the replica set.
 
 MongoDB writes the rollback data to a :term:`BSON` file in the
 database's :setting:`dbpath` directory. Use :doc:`bsondump
@@ -565,7 +565,8 @@ and then manually apply the changes to the new primary. There is no
 way for MongoDB to appropriately and fairly handle rollback situations
 without manual intervention. Since rollback situations require an
 administrator's direct intervention, users should strive to avoid
-rollbacks as much as possible.
+rollbacks as much as possible. Until an administrator applies this
+rollback data, the former primary remains in a "rollback" status.
 
 The best strategy for avoiding all rollbacks is to ensure :ref:`write
 propagation <replica-set-write-propagation>` to all or some of the
@@ -578,6 +579,13 @@ that might create rollbacks.
    megabytes of data. If your system needs to rollback more than 300
    MB, you will need to manually intervene to recover this data.
 
+.. note::
+
+   After a rollback occurs, the former primary will remain in a
+   "rollback" mode until the administrator deals with the rolled back
+   data and restarts the :option:`mongod` instance. Only then can the
+   node becomes a normal :term:`secondary` terms.
+
 .. _replica-set-write-propagation:
 
 Write Propagation

source/core/replication.rst

@@ -49,7 +49,7 @@ Core Concepts and Functionality
    core/map-reduce
    core/journaling
    core/capped-collections
-   core/indexes
+   core/indexing
 
 Administration and Deployment
 -----------------------------

source/index.rst

@@ -30,6 +30,7 @@ Statuses and Errors
    reference/server-status
    reference/database-statistics
    reference/collection-statistics
+   reference/collection-validation
    reference/replica-status
    reference/replica-configuration
    reference/replication-info

source/reference.rst

@@ -0,0 +1,121 @@
+================================
+Collection Validation Statistics
+================================
+
+.. default-domain:: mongodb
+
+Synopsis
+--------
+
+The collection validation command checks all of the structures within
+a name space for correctness and returns a :term:`JSON Document`
+containing information
+
+Run the validation command in the :option:`mongo` shell using the
+following form to validate a collection named "``people``":
+
+.. code-block:: javascript
+
+   db.people.validate()
+
+Alternatively you can use the command prototype and the
+:js.func:`runCommand()` shell method in the following form:
+
+.. code-block:: javascript
+
+   db.runCommand( { validate: "people", full: true } )
+   db.people.validate(true)
+
+.. seealso:: ":dbcommand:`validate`" and ":js:func:`validate()`."
+
+Values
+------
+
+.. js:data:: ns
+
+.. js:data:: firstExtent
+
+.. js:data:: lastExtent
+
+.. js:data:: extentCount
+
+.. js::data:: extents
+
+   .. note::
+
+      This sub-document is only returned when you specify the "``full``" option.
+
+   .. js::data:: extents.loc
+
+   .. js::data:: extents.xnext
+
+   .. js::data:: extents.xprev
+
+   .. js::data:: extents.nsdaig
+
+   .. js::data:: extents.size
+
+   .. js::data:: extents.firstRecord
+
+   .. js::data:: extents.lastRecord
+
+.. js:data:: datasize
+
+.. js:data:: nsrecords
+
+.. js:data:: lastExtentSize
+
+.. js:data:: padding
+
+.. js:data:: firstExtentDetails
+
+   .. js:data:: firstExtentDetails.loc
+
+   .. js:data:: firstExtentDetails.xnext
+
+   .. js:data:: firstExtentDetails.xprev
+
+   .. js:data:: firstExtentDetails.nsdiag
+
+   .. js:data:: firstExtentDetails.size
+
+   .. js:data:: firstExtentDetails.firstRecord
+
+   .. js:data:: firstExtentDetails.lastRecord
+
+.. js:data:: objectsFound
+
+.. js:data:: invalidObjects
+
+   .. note::
+
+      This field is only included in the validation output when you
+      specify the "``full``" option.
+
+.. js:data:: byteswWithHeaders
+
+   .. note::
+
+      This field is only included in the validation output when you
+      specify the "``full``" option.
+
+.. js:data:: bytesWithoutHeaders
+
+   .. note::
+
+      This field is only included in the validation output when you
+      specify the "``full``" option.
+
+.. js:data:: deletedCount
+
+.. js:data:: deletedSize
+
+.. js:data:: nIndexes
+
+.. js:data:: keysPerIndex
+
+.. js:data:: valid
+
+.. js:data:: errors
+
+.. js:data:: ok