diff --git a/draft/applications/geospatial-indexes.txt b/draft/applications/geospatial-indexes.txt index 1e2292a833a..7823b2b47f7 100644 --- a/draft/applications/geospatial-indexes.txt +++ b/draft/applications/geospatial-indexes.txt @@ -35,7 +35,7 @@ command, this is the same as running database commands. The :dbcommand:`geoNear` command is more specialized as it returns detailed geospatial information for each result such as distance and -overall query performance. This provides addtional benefits when only +overall query performance. This provides additional benefits when only working with geospatial data. .. TODO does it make sense to have this here?? @@ -371,7 +371,7 @@ spherical geometry is the ``{ spherical: true }`` option. sphere (e.g. the Earth) in the same units as the distance measurement. - - *radians to distnace*: multiply the radian measure by the radius + - *radians to distance*: multiply the radian measure by the radius of the sphere (e.g. the Earth) in the units system that you want to convert the distance to. @@ -566,7 +566,7 @@ model: } The values of the array may either be arrays holding coordinates, as -in ``[ 55.5, 42.3 ]`` or embeded documents as in ``{ "lat": 55.3, +in ``[ 55.5, 42.3 ]`` or embedded documents as in ``{ "lat": 55.3, "long": 40.2 }``. You could then create a geospatial index on the ``locs`` field, as in diff --git a/draft/core/read-operations.txt b/draft/core/read-operations.txt index 831f37d0009..4dc9f89e5be 100644 --- a/draft/core/read-operations.txt +++ b/draft/core/read-operations.txt @@ -288,7 +288,7 @@ Replica Sets :term:`Replica sets ` use :term:`read preferences ` to determine where and how to route read operations. By -default, MongoDB always reads data from a repilca set's :term:`primary`. +default, MongoDB always reads data from a replica set's :term:`primary`. You can modify that behavior by changing the :ref:`read preference mode `. diff --git a/draft/faq-sharding-addition.txt b/draft/faq-sharding-addition.txt index f6c0b60c08c..baa1ef949a5 100644 --- a/draft/faq-sharding-addition.txt +++ b/draft/faq-sharding-addition.txt @@ -25,7 +25,7 @@ In the following cases, we recommend pre-splitting before a large insert: chunks. By pre-splitting and using an increasing shard key, you can prevent writes from monopolizing a single :term:`shard`. -- Monotomically increasing shard key. +- Monotonically increasing shard key. If you attempt to insert data with monotonically increasing shard keys, the writes will always occur on the last chunk in the diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index 131d64780f6..27de5456da5 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -10,7 +10,7 @@ Least recently used, or LRU, data retention patterns are used in simple data caches or support for stateless systems. By extending TTL collections with application support provides additional features. -This pattern presents some cases and proides a pattern for maintaining +This pattern presents some cases and provides a pattern for maintaining documents in MongoDB where LRU documents are retained while others are removed using the TTL collection feature. diff --git a/draft/use-cases/ad-campaign-management.txt b/draft/use-cases/ad-campaign-management.txt index 1dc255698c1..85851636af2 100644 --- a/draft/use-cases/ad-campaign-management.txt +++ b/draft/use-cases/ad-campaign-management.txt @@ -9,7 +9,7 @@ Online Advertising: Campaign Management Overview -------- -This document outlines the basic patterns and principless for using +This document outlines the basic patterns and principles for using MongoDB as a persistent storage engine for an online advertising network. In particular, this document focuses on creating and maintaining an advertising campaign with a pre-set daily budget and cost per click (CPC) and cost per diff --git a/draft/use-cases/gaming-user-state.txt b/draft/use-cases/gaming-user-state.txt index 8b2b5bc7a85..eb447e57004 100644 --- a/draft/use-cases/gaming-user-state.txt +++ b/draft/use-cases/gaming-user-state.txt @@ -33,7 +33,7 @@ include: location to another, the character needs to track this. In addition, you need to store all this data for large numbers of -playerss who might be playing the game simultaneously, and this data +players who might be playing the game simultaneously, and this data needs to be both readable and writeable with minimal latency in order to ensure responsiveness during gameplay. @@ -143,7 +143,7 @@ There are a few things to note about this document: .. should note that using unbounded lists on items can be an issue, past 1000 entries should prob normalize. Also if it ends up being much larger than core data itself, may want to split into own document, to better use RAM. -.. Dont understand why the whole location info is stored here: lots of duplication and consistency issues. +.. Don't understand why the whole location info is stored here: lots of duplication and consistency issues. Should normalize here and just store location name / coordinates Items @@ -361,7 +361,7 @@ To actually display weapons, then, you would use the following code: .. code-block:: pycon - >>> armor = get_weapons_for_dislay(character, item_index) + >>> armor = get_weapons_for_display(character, item_index) Displaying Character Attributes, Inventory, and Room Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/draft/use-cases/serving-ads.txt b/draft/use-cases/serving-ads.txt index 48fb26a12f2..b0e21970258 100644 --- a/draft/use-cases/serving-ads.txt +++ b/draft/use-cases/serving-ads.txt @@ -7,7 +7,7 @@ Serving and Tracking Online Advertisements Overview -------- -This document outlines basic patterns and principless for using +This document outlines basic patterns and principles for using MongoDB as a persistent storage engine for an online advertising network. In particular, this document focuses on the task of deciding *which* ad to serve when a user visits a particular site. @@ -243,7 +243,7 @@ Querying ```````` Use the following query to choose an ad to serve. This operation must -iterate through ads in order of "desireability" and then select the +iterate through ads in order of "desirability" and then select the "best" ad that also satisfies the advertiser's targeting rules. In this example the frequency cap is the targeting rule. @@ -293,7 +293,7 @@ determine if it meets the advertiser's rules. The ``ad_is_acceptable()`` function then iterates over all ``impressions`` in the user's' profile, from most recent to oldest, -within a certain ``thresold`` time period, which is 1 day in the +within a certain ``threshold`` time period, which is 1 day in the sample above. If the same ``ad_unit_id`` appears in the impression stream, the function rejects the ad. Otherwise the service shows the first acceptable ad to the user. diff --git a/draft/use-cases/social-networking-updates-and-profiles.txt b/draft/use-cases/social-networking-updates-and-profiles.txt index 3b06885737c..b209417a3d4 100644 --- a/draft/use-cases/social-networking-updates-and-profiles.txt +++ b/draft/use-cases/social-networking-updates-and-profiles.txt @@ -7,7 +7,7 @@ Storing Updates and Profiles for Social Networking Sites Overview -------- -This document outlines the basic patterns and principless for using +This document outlines the basic patterns and principles for using MongoDB as a persistent storage engine for a social networking website. In particular, this case study focuses on the task of storing and displaying user updates. @@ -257,7 +257,7 @@ Consider the following features of this schema: .. not sure this collection is useful, instead just use the post collection. Posts should have an index on {user, time} and hence it is efficient to retrieve the wall. Also wall may be scrolled down to get further items. - Dont think it's worth updating this document every time a user posts. + Don't think it's worth updating this document every time a user posts. The second dependent collection is is ``social.news``, which collects posts from people the user follows. These documents duplicate @@ -530,7 +530,7 @@ The basic sequence of operations in the code above is the following: #. The post first saved into the "system of record," the ``social.post`` collection. -#. The recipient's wall is updatd with the post. +#. The recipient's wall is updated with the post. #. Updates news feeds of everyone who is "circled" in the post. diff --git a/source/administration/monitoring.txt b/source/administration/monitoring.txt index 5c7d5badb3e..52785930664 100644 --- a/source/administration/monitoring.txt +++ b/source/administration/monitoring.txt @@ -242,7 +242,7 @@ there is a chance that a large number of requests are waiting for a lock. This indicates a possible concurrency issue that might effect performance. -If :status:`globalLock.toalTime` is high in context of +If :status:`globalLock.totalTime` is high in context of :status:`uptime` then the database has existed in a lock state for a significant amount of time. If :status:`globalLock.ratio` is also high, MongoDB has likely been processing a large number of long diff --git a/source/applications/database-references.txt b/source/applications/database-references.txt index d427aadfffd..ab22ece147f 100644 --- a/source/applications/database-references.txt +++ b/source/applications/database-references.txt @@ -79,7 +79,7 @@ document: db.people.insert({ "name": "Erin" "places_id": original_id - "url": "bc.exmaple.net/Erin" + "url": "bc.example.net/Erin" }) Then, when a query returns the document from the ``people`` collection @@ -164,7 +164,7 @@ Support The :api:`DBRef ` class provides supports for DBRefs from Java. -**JavaScrpt** +**JavaScript** The :program:`mongo` shell's :doc:`JavaScript ` interface provides a DBRef. diff --git a/source/core/sharding-internals.txt b/source/core/sharding-internals.txt index 8bf8a4805c9..8d9f526fd11 100644 --- a/source/core/sharding-internals.txt +++ b/source/core/sharding-internals.txt @@ -487,7 +487,7 @@ All chunk migrations use the following procedure: the source shard for the chunk. In this operation the balancer passes the name of the destination shard to the source shard. -#. The source initaties the move with an internal +#. The source initiates the move with an internal :dbcommand:`moveChunk` command with the destination shard. #. The destination shard begins requesting documents in the chunk, and diff --git a/source/faq/indexes.txt b/source/faq/indexes.txt index 9c63d5f51e9..d8c9773347a 100644 --- a/source/faq/indexes.txt +++ b/source/faq/indexes.txt @@ -25,7 +25,7 @@ index as data changes. While running :method:`ensureIndex() ` is usually ok, if an index doesn't exist because of ongoing administrative work, a call to :method:`ensureIndex() ` -may disrupt database avalability. Runnning :method:`ensureIndex() +may disrupt database availability. Running :method:`ensureIndex() ` can render a replica set inaccessible as the index creation is happening. See :ref:`index-building-replica-sets`. diff --git a/source/reference.txt b/source/reference.txt index 02cf1089d76..8a68f4dd867 100644 --- a/source/reference.txt +++ b/source/reference.txt @@ -10,7 +10,7 @@ MongoDB Interface .. see:: The following interface overview pages: :doc:`/reference/operators` for an overview of all query, update, and projection operators; :doc:`/reference/meta-query-operators` - for all speical "meta" query operators; + for all special "meta" query operators; :doc:`/reference/aggregation` for all :doc:`aggregation ` operators; :doc:`/reference/commands` for an overview of all :term:`database commands `; and diff --git a/source/reference/aggregation/sort.txt b/source/reference/aggregation/sort.txt index 79fafd131b3..7271c52d6b4 100644 --- a/source/reference/aggregation/sort.txt +++ b/source/reference/aggregation/sort.txt @@ -44,7 +44,7 @@ $sort (aggregation) - :agg:pipeline:`$skip` :pipeline:`$sort` operator can take advantage of an index when - placed at the **beginning** of the pipleline or placed **before** + placed at the **beginning** of the pipeline or placed **before** the following aggregation operators: - :agg:pipeline:`$project` diff --git a/source/reference/command/compact.txt b/source/reference/command/compact.txt index d6db50ece48..fc75e5df91d 100644 --- a/source/reference/command/compact.txt +++ b/source/reference/command/compact.txt @@ -143,8 +143,8 @@ compact space. - :dbcommand:`compact` may increase the total size and number of our - data files, expecially when run for the first time. However, this - will not increase the total colletion storage space since storage + data files, especially when run for the first time. However, this + will not increase the total collection storage space since storage size is the amount of data allocated within the database files, and not the size/number of the files on the file system. diff --git a/source/reference/command/geoNear.txt b/source/reference/command/geoNear.txt index 95df135f546..36a8d106fba 100644 --- a/source/reference/command/geoNear.txt +++ b/source/reference/command/geoNear.txt @@ -39,7 +39,7 @@ geoNear coordinate system references points on a spherical plane rather than a plane. - :field distanceMultipler: Optional. Specifies a factor to multiply + :field distanceMultiplier: Optional. Specifies a factor to multiply all distances returned by :dbcommand:`geoNear`. For example, use ``distanceMultiplier`` to convert from diff --git a/source/reference/method/cursor.forEach.txt b/source/reference/method/cursor.forEach.txt index 9a47d9d926e..5d57dbab266 100644 --- a/source/reference/method/cursor.forEach.txt +++ b/source/reference/method/cursor.forEach.txt @@ -1,6 +1,6 @@ -================= -cursor.forEarch() -================= +================ +cursor.forEach() +================ .. default-domain:: mongodb diff --git a/source/reference/operator/not.txt b/source/reference/operator/not.txt index ee9d2ca225d..aca4f9a03bb 100644 --- a/source/reference/operator/not.txt +++ b/source/reference/operator/not.txt @@ -43,10 +43,10 @@ $not - The :operator:`$not` operator does **not** support operations with the :operator:`$regex` operator. Instead use ``//`` or in your - driver interfaces, use your langauge's regular expression + driver interfaces, use your language's regular expression capability to create regular expression objects. - Consider the following example whiche uses the pattern match expression ``//``: + Consider the following example which uses the pattern match expression ``//``: .. code-block:: javascript diff --git a/source/reference/operator/polygon.txt b/source/reference/operator/polygon.txt index 31387ae03a0..f3b907fbb52 100644 --- a/source/reference/operator/polygon.txt +++ b/source/reference/operator/polygon.txt @@ -8,7 +8,7 @@ $polygon .. versionadded:: 1.9 - Use :operator:`$polygon` to specify a polgon for a bounded query + Use :operator:`$polygon` to specify a polygon for a bounded query using the :operator:`$within` operator for :term:`geospatial` queries. To define the polygon, you must specify an array of coordinate points, as in the following: @@ -16,7 +16,7 @@ $polygon [ [ x1,y1 ], [x2,y2], [x3,y3] ] The last point specified is always implicitly connected to the - first. You can specify as many points, and therfore sides, as you + first. You can specify as many points, and therefore sides, as you like. Consider the following bounded query for documents with coordinates within a polygon: diff --git a/source/reference/server-status-index.txt b/source/reference/server-status-index.txt index 1d05e8f911b..7582e96713f 100644 --- a/source/reference/server-status-index.txt +++ b/source/reference/server-status-index.txt @@ -17,7 +17,7 @@ documentation of the content of this output, see .. note:: The fields included in this output vary slightly depending on the - version of MongoDB, underlaying operating system platform, and the + version of MongoDB, underlying operating system platform, and the kind of node, including :program:`mongos`, :program:`mongod` or :term:`replica set` member. diff --git a/source/tutorial/deploy-replica-set.txt b/source/tutorial/deploy-replica-set.txt index afead869121..5182918fae6 100644 --- a/source/tutorial/deploy-replica-set.txt +++ b/source/tutorial/deploy-replica-set.txt @@ -63,7 +63,7 @@ The examples in this procedure create a new replica set named ``rs0``. systems. a. Create the necessary data directories by issuing a command - similiar to the following: + similar to the following: .. code-block:: sh diff --git a/source/tutorial/deploy-shard-cluster.txt b/source/tutorial/deploy-shard-cluster.txt index b3a7d614997..ce6710ea74d 100644 --- a/source/tutorial/deploy-shard-cluster.txt +++ b/source/tutorial/deploy-shard-cluster.txt @@ -86,7 +86,7 @@ You would issue the following command: .. [#names] Use DNS names for the config servers rather than explicit IP addresses for operational flexibility. If you're not using resolvable - hostame, + hostname, you cannot change the config server names or IP addresses without a restarting *every* :program:`mongos` and :program:`mongod` instance.