Update jsonSchema.txt

changelogs/generatechangelogs.py

@@ -52,7 +52,7 @@ def get_jira_issues(fixVersion):
     # Run the JIRA query
     query = "project in {0} and fixVersion = {1} and resolution = 'Fixed' ORDER BY key ASC".format(
         projects, fixVersion)
-    issues = auth_jira.search_issues(query, maxResults=200)
+    issues = auth_jira.search_issues(query, maxResults=500)
 
     logger.info("building changelog for {0} with {1} issue(s)".format(
         fixVersion, len(issues)))

conf.py

@@ -76,7 +76,7 @@ def has(self, *args):
 ])
 
 source_constants = {
-    'version-dev': '4.9',   # Current development branch
+    'version-dev': '4.3',   # Current development branch
     'package-name-org': 'mongodb-org',
     'package-name-enterprise': 'mongodb-enterprise',
     'version': version,

config/build_conf.yaml

@@ -10,8 +10,8 @@ project:
   branched: true
   siteroot: true
 version:
-  release: '5.0.0'
-  branch: '5.0'
+  release: '4.4.3'
+  branch: '4.4'
 system:
   files:
     - 'pdfs.yaml'

config/changelog_conf.yaml

@@ -47,6 +47,7 @@ groups:
     - Mobile
   "Internals":
     - Testing
+    - Python tests
     - Testing Infrastructure
     - Stability
     - Performance

config/sphinx_local.yaml

@@ -89,7 +89,6 @@ theme:
     - /release-notes/4.0
     - /release-notes/4.2
     - /release-notes/4.4
-    - /release-notes/5.0
     - /security
     - /sharding
     - /changeStreams

snooty.toml

@@ -1,11 +1,11 @@
 name = "manual"
 
 [constants]
-package-branch = "5.0" # For rc = testing.  For GA, will be 4.2.
-windows-dir-version = "5.0" # The wizard installs in 4.2 branch
+package-branch = "4.4" # For rc = testing.  For GA, will be 4.2.
+windows-dir-version = "4.4" # The wizard installs in 4.2 branch
 package-name-org = "mongodb-org"
 package-name-enterprise = "mongodb-enterprise"
-version = "5.0"
+version = "4.4"
 release = "{+release+}"
 pgp-version = "{+version+}"
 pgp-fingerprint = "E162F504A20CDF15827F718D4B7C549A058F8B6B"

source/administration/configuration.txt

@@ -21,20 +21,9 @@ best-practice configurations for common use cases.
 
 While both interfaces provide access to the same collection of options
 and settings, this document primarily uses the configuration file
-interface. If you installed MongoDB with a package manager such as
-``yum`` or ``apt`` on Linux, or ``brew`` on macOS, a default
-:doc:`configuration file </reference/configuration-options>` has been
-provided as part of your installation:
+interface.
 
-- On Linux, a default :file:`/etc/mongod.conf` configuration file is
-  included when using a package manager to install MongoDB.
-
-- On Windows, a default :file:`<install directory>/bin/mongod.cfg`
-  configuration file is included during the installation.
-
-- On macOS, a default :file:`/usr/local/etc/mongod.conf`
-  configuration file is included when installing from MongoDB's
-  official Homebrew tap.
+.. include:: /includes/fact-default-conf-file.rst
 
 For package installations of MongoDB on Linux or macOS, an
 initialization script which uses this default configuration file is also
@@ -67,14 +56,14 @@ to create your own configuration file. A
 this document. Once you have created a configuration file, you can start
 a MongoDB instance with this configuration file by using either the
 :option:`--config <mongod --config>` or :option:`-f <mongod --config>`
-options to :binary:`~bin.mongod`:
+options to :binary:`~bin.mongod`. For example, on Linux:
 
 .. code-block:: sh
 
    mongod --config /etc/mongod.conf
    mongod -f /etc/mongod.conf
 
-Modify the values in the ``/etc/mongod.conf`` file on your system to
+Modify the values in the ``mongod.conf`` file on your system to
 control the configuration of your database instance.
 
 .. _base-config:

source/administration/production-notes.txt

@@ -97,7 +97,7 @@ Recommended Platforms
 ~~~~~~~~~~~~~~~~~~~~~
 
 While MongoDB supports a variety of platforms, the following operating
-systems are recommended for production use:
+systems are recommended for production use on ``x86_64`` architecture:
 
 - Amazon Linux 2
 - Debian 9 and 10

source/aggregation.txt

@@ -41,7 +41,7 @@ transforms the documents into an aggregated result. For example:
 
       <video style="width:100%;" src="_images/agg-pipeline.mp4" controls> </video>
 
-In the example,
+In the example:
 
 .. code-block:: javascript
 
@@ -82,28 +82,6 @@ internal optimization phase. See
 :ref:`aggregation-pipeline-operators-and-performance` and
 :doc:`/core/aggregation-pipeline-optimization` for details.
 
-.. _aggregation-map-reduce:
-
-Map-Reduce
-----------
-
-.. tip::
-
-   :doc:`Aggregation pipeline </core/aggregation-pipeline>`
-   provides better performance and a more coherent interface than
-   map-reduce.
-
-   For examples of aggregation alternatives to map-reduce operations,
-   see :doc:`/tutorial/map-reduce-examples`. See also
-   :doc:`/reference/map-reduce-to-aggregation-pipeline`.
-
-MongoDB also provides :doc:`map-reduce </core/map-reduce>` operations
-to perform aggregation. Map-reduce uses custom JavaScript functions to
-perform the map and reduce operations, as well as the optional
-*finalize* operation.
-
-.. include:: /images/map-reduce.rst
-
 .. _single-purpose-agg-operations:
 
 Single Purpose Aggregation Operations
@@ -114,11 +92,18 @@ MongoDB also provides :method:`db.collection.estimatedDocumentCount()`,
 
 All of these operations aggregate documents from a single collection.
 While these operations provide simple access to common aggregation
-processes, they lack the flexibility and capabilities of the
-aggregation pipeline and map-reduce.
+processes, they lack the flexibility and capabilities of an aggregation
+pipeline.
 
 .. include:: /images/distinct.rst
 
+.. _aggregation-map-reduce:
+
+Map-Reduce
+----------
+
+.. include:: /includes/fact-use-aggregation-not-map-reduce.rst
+
 Additional Features and Behaviors
 ---------------------------------
 

source/core/aggregation-pipeline.txt

@@ -29,7 +29,7 @@ results. For example:
 
       <video style="width:100%;" src="../_images/agg-pipeline.mp4" controls> </video>
 
-In the example,
+In the example:
 
 .. code-block:: javascript
 
@@ -53,8 +53,8 @@ Pipeline
 
 The MongoDB aggregation pipeline consists of :ref:`stages
 <aggregation-pipeline-operator-reference>`. Each stage transforms the
-documents as they pass through the pipeline. Pipeline stages do not
-need to produce one output document for every input document; e.g.,
+documents as they pass through the pipeline. Pipeline stages do not need
+to produce one output document for every input document. For example,
 some stages may generate new documents or filter out documents.
 
 Pipeline stages can appear multiple times in the pipeline with the
@@ -98,11 +98,11 @@ by the aggregation process with one exception: :ref:`accumulator
 <aggregation-accumulator-operators>` expressions.
 
 The accumulators, used in the :pipeline:`$group` stage, maintain their
-state (e.g. totals, maximums, minimums, and related data) as documents
-progress through the pipeline. Some accumulators are available in the
-:pipeline:`$project` stage; however, when used in the
-:pipeline:`$project` stage, the accumulators do not maintain their
-state across documents.
+state (for example, totals, maximums, minimums, and related data) as
+documents progress through the pipeline. Some accumulators are available
+in the :pipeline:`$project` stage; however, when used in the
+:pipeline:`$project` stage, the accumulators do not maintain their state
+across documents.
 
 Starting in version 4.4, MongoDB provides the :group:`$accumulator` and
 :expression:`$function` aggregation operators. These operators provide
@@ -194,41 +194,29 @@ pipeline.
 Considerations
 --------------
 
-Sharded Collections
-~~~~~~~~~~~~~~~~~~~~
+Aggregation Pipeline Limitations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The aggregation pipeline supports operations on sharded collections.
-See :ref:`aggregation-pipeline-sharded-collection`.
-
-Aggregation Pipeline vs Map-Reduce
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+An aggregation pipeline has some limitations on the value types and
+the result size. See :doc:`/core/aggregation-pipeline-limits`.
 
-The aggregation pipeline provides better performance and a more coherent
-interface than :doc:`map-reduce </core/map-reduce>`.
+Aggregation Pipeline Optimization
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Various map-reduce operations can be rewritten using :doc:`aggregation
-pipeline operators </meta/aggregation-quick-reference>`, such as
-:pipeline:`$group`, :pipeline:`$merge`, etc. For map-reduce operations
-that require custom functionality, MongoDB provides the
-:group:`$accumulator` and :expression:`$function` aggregation operators
-starting in version 4.4. These operators provide users with the ability
-to define custom aggregation expressions in JavaScript.
+An aggregation pipeline has an internal optimization phase that provides
+improved performance for certain sequences of operators. See
+:doc:`/core/aggregation-pipeline-optimization`.
 
-See :doc:`/tutorial/map-reduce-examples` for details.
-
-Limitations
-~~~~~~~~~~~
+Aggregation on Sharded Collections
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Aggregation pipeline have some limitations on value types and result
-size. See :doc:`/core/aggregation-pipeline-limits` for details on
-limits and restrictions on the aggregation pipeline.
+An aggregation pipeline supports operations on sharded collections.
+See :ref:`aggregation-pipeline-sharded-collection`.
 
-Pipeline Optimization
-~~~~~~~~~~~~~~~~~~~~~
+Aggregation Pipeline as an Alternative to Map-Reduce
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The aggregation pipeline has an internal optimization phase that
-provides improved performance for certain sequences of operators. For
-details, see :doc:`/core/aggregation-pipeline-optimization`.
+.. include:: /includes/fact-use-aggregation-not-map-reduce.rst
 
 .. toctree::
    :titlesonly:

source/core/data-modeling-introduction.txt

@@ -22,7 +22,7 @@ Flexible Schema
 
 Unlike SQL databases, where you must determine and declare a table's
 schema before inserting data, MongoDB's :term:`collections
-<collection>`, by default, does not require its :doc:`documents
+<collection>`, by default, do not require their :doc:`documents
 </core/document>` to have the same schema. That is:
 
 - The documents in a single collection do not need to have the same set

source/core/index-compound.txt

@@ -39,10 +39,22 @@ operation that resembles the following prototype:
 
 .. include:: /includes/fact-index-specification-field-value.rst
 
-.. important:: You may not create compound indexes that have
-   ``hashed`` index type. You will receive an error if you attempt to
-   create a compound index that includes :doc:`a hashed index
-   field </core/index-hashed>`.
+.. important:: 
+
+   Starting in MongoDB 4.4: 
+
+   - Compound indexes may contain **a single** :doc:`hashed index field 
+     </core/index-hashed>`. 
+   - You will receive an error if you attempt to create a compound index 
+     that contains more than one :doc:`hashed index field 
+     </core/index-hashed>`.
+
+   In MongoDB 4.2 or earlier: 
+
+   - Compound indexes may **not** contain a :doc:`hashed index field 
+     </core/index-hashed>`. 
+   - You will receive an error if you attempt to create a compound index
+     that contains a :doc:`hashed index field </core/index-hashed>`.
 
 Consider a collection named ``products`` that holds documents that
 resemble the following document:

source/core/index-creation.txt

@@ -129,21 +129,25 @@ Index Build Impact on Database Performance
 ------------------------------------------
 
 Index Builds During Write-Heavy Workloads
-  Building indexes during time periods where the target collection
-  is under heavy write load can result in reduced write 
-  performance and longer index builds.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-  Consider designating a maintenance window during which applications
-  stop or reduce write operations against the collection. Start the
-  index build during this maintenance window to mitigate the
-  potential negative impact of the build process.
+Building indexes during time periods where the target collection
+is under heavy write load can result in reduced write 
+performance and longer index builds.
+
+Consider designating a maintenance window during which applications
+stop or reduce write operations against the collection. Start the
+index build during this maintenance window to mitigate the
+potential negative impact of the build process.
 
 Insufficient Available System Memory (RAM)
-  .. include:: /includes/fact-index-build-default-memory-limit.rst
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. include:: /includes/fact-index-build-default-memory-limit.rst
 
-  If the host machine has limited available free RAM, you may need
-  to schedule a maintenance period to increase the total system RAM
-  before you can modify the :binary:`~bin.mongod` RAM usage.
+If the host machine has limited available free RAM, you may need
+to schedule a maintenance period to increase the total system RAM
+before you can modify the :binary:`~bin.mongod` RAM usage.
 
 .. _index-operations-replicated-build:
 .. _index-operations-simultaneous-build:
@@ -190,21 +194,6 @@ The build process is summarized as follows:
 For sharded clusters, the index build occurs only on shards
 containing data for the collection being indexed.
 
-.. warning::
-
-  Avoid dropping any index on a collection while an index is being 
-  replicated on the secondaries.
-
-  If you attempt to drop an index from a collection on a :term:`primary` 
-  node while the collection has a background index building on the 
-  :term:`secondary` nodes, the two indexing operations will conflict 
-  with each other. 
-
-  As a result, reads will be halted across all namespaces and
-  replication will halt until the background index build completes. 
-  When the build finishes the dropIndex action will execute, then 
-  reads and replication will resume. 
-
 For a more detailed description of the index build process, 
 see :ref:`index-build-process`.