DOCS-663 small typo fixes to read operations and a quick sentence regard...

draft/core/read-operations.txt

@@ -10,7 +10,7 @@ modifying data are read operations. In MongoDB, all read operations or
 :term:`documents` that match the query criteria in a collection.
 
 This document describes the syntax and structure of queries, which
-describe how applications request how MongoDB performs read
+determines how applications make requests to MongoDB to perform read
 operations and how different factors affect the efficiency of reads.
 
 .. note::
@@ -28,39 +28,38 @@ operations and how different factors affect the efficiency of reads.
 Queries in MongoDB
 ------------------
 
-In the :program:`mongo` shell the :method:`find()
+In the :program:`mongo` shell, the :method:`find()
 <db.collection.find()>` and :method:`findOne()
 <db.collection.findOne()>` methods perform read operations. The
-:method:`find() <db.collection.find()>` method is has the following
+:method:`find() <db.collection.find()>` method has the following
 syntax:
 
 .. code-block:: javascript
 
    db.collection.find( <query>, <projection> )
 
-- The ``db.collection`` object, describes the database and collection
+- The ``db.collection`` object specifies the database and collection
   to query. All queries in MongoDB address a *single* collection.
 
   You can enter ``db`` in the :program:`mongo` shell to return the
   name of the current database. Use the ``show collections`` operation
   in the :program:`mongo` shell to list the current collections in the
   database.
 
-- Queries in MongoDB have a JSON-like syntax, and take the form of a
-  :term:`document` using a collection of :doc:`/reference/operators`
-  query operators to describe query parameters.
+- Queries in MongoDB have a JSON-like syntax and take the form of a
+  :term:`document` using a set of :doc:`query operators
+  </reference/operators>` to describe query parameters.
 
   The ``<query>`` argument of the :method:`find()
-  <db.collection.find()>` method holds this query document. A query,
-  without a query document will return all documents in the
+  <db.collection.find()>` method holds this query document. A read
+  operation without a query document will return all documents in the
   collection.
 
-- The ``<projection>`` argument describes describes the result or
-  return set in the form of a document. Projections specify or limit
-  the fields to return.
+- The ``<projection>`` argument describes the result set in the form of
+  a document. Projections specify or limit the fields to return.
 
-  Without a projection the operation will return all
-  fields of all documents, specify a projection if your documents are
+  Without a projection, the operation will return all
+  fields of the documents. Specify a projection if your documents are
   larger, or when your application only needs a subset of available
   fields.
 
@@ -94,7 +93,7 @@ operators, refer to the :doc:`/applications/read` page of the
 Query Document
 ~~~~~~~~~~~~~~
 
-This section provides an overview of query document for MongoDB
+This section provides an overview of the query document for MongoDB
 queries. See the preceding section for more information on
 :ref:`queries in MongoDB <read-operations-query-operations>`. 
 
@@ -112,7 +111,7 @@ collection of documents named ``inventory``:
 
   Not specifying a query document to the :method:`find()
   <db.collection.find()>` is equivalent to specifying an empty query
-  document. Therefore the following operation is equivelent to the
+  document. Therefore the following operation is equivalent to the
   previous operation: 
 
   .. code-block:: javascript
@@ -123,26 +122,25 @@ collection of documents named ``inventory``:
   field has a certain value. These are simple "equality" queries.
 
   In the following example, the query selects all documents in the
-  collection where the ``type`` field has the value ``snacks``:
+  collection where the ``type`` field has the value ``'snacks'``:
 
   .. code-block:: javascript
 
      db.inventory.find( { type: "snacks" } )
 
-  When the field holds an array, these equality matches select
-  documents if only *one* of the elements in the array match the
-  specified value. In the following example, the query will match all
-  documents where the array in the ``tags`` field contains the element
-  ``fruit``:
+  When the field holds an array, these equality matches documents if at
+  least *one* element in the array match the specified value. In the
+  following example, the query will match all documents where the array
+  in the ``tags`` field contains the element ``'fruit'``:
 
   .. code-block:: javascript
 
      db.inventory.find( { tags: "fruit" } )
 
 - A single-clause query document can also select all documents in a
-  collection given a condition or set of conditions for one field
-  in the collection's documents. Specify conditions in a MongoDB
-  query, using the :ref:`query operators <query-operators>`.
+  collection given a condition or set of conditions for one field in
+  the collection's documents. Use the :ref:`query operators
+  <query-operators>` to specify conditions in a MongoDB query.
 
   In the following example, the query selects all documents in the
   collection where the value of the ``type`` field is either
@@ -160,10 +158,9 @@ collection of documents named ``inventory``:
      same field.
 
 - A compound query can specify conditions for more than one field in
-  the collection's documents. Implicitly, a logical ``AND``
-  conjunction connects the clauses of a compound query so that all
-  specified conditions for a query must be true for the query to
-  select a document.
+  the collection's documents. Implicitly, a logical ``AND`` conjunction
+  connects the clauses of a compound query so that the query selects
+  the documents in the collection that match all the conditions.
 
   In the following example, the query document specifies an equality
   match on a single field, followed by a range of values for a second
@@ -174,13 +171,13 @@ collection of documents named ``inventory``:
      db.inventory.find( { type: 'food', price: { $lt: 9.95 } } )
 
   This query selects all documents where the ``type`` field has the
-  value ``food`` **and** the value of the ``price`` field is less than
+  value ``'food'`` **and** the value of the ``price`` field is less than
   (i.e. :operator:`$lt`) ``9.95``.
 
-- Using the :operator:`$or` you can specify a compound query that
-  joins each clause with a logical ``OR`` conjunction so that the
-  query will select documents that match only one of the query's
-  clauses.
+- Using the :operator:`$or` operator, you can specify a compound query
+  that joins each clause with a logical ``OR`` conjunction so that the
+  query selects the documents in the collection that match at least one
+  condition.
 
   In the following example, the query document selects all documents
   in the collection where the field ``qty`` has a value greater than
@@ -216,9 +213,9 @@ documentation of all query operators.
 Result Projections
 ~~~~~~~~~~~~~~~~~~
 
-The :term:`projection` specification, limits the fields to return for
+The :term:`projection` specification limits the fields to return for
 all matching documents. Constraining the result set by restricting the
-fields to return, can minimize network transit costs and the costs of
+fields to return can minimize network transit costs and the costs of
 deserializing documents in the application layer. 
 
 The second argument to the :method:`find() <db.collection.find()>`
@@ -233,7 +230,7 @@ included, unless explicitly excluded.
    You cannot combine inclusion and exclusion semantics in a single
    projection with the *exception* of the ``_id`` field.
 
-Consider the following projection specifications, in :method:`find()
+Consider the following projection specifications in :method:`find()
 <db.collection.find()>` operations:
 
 - If you specify no projection, the :method:`find()
@@ -245,12 +242,12 @@ Consider the following projection specifications, in :method:`find()
      db.inventory.find( { type: 'food' } )
 
   This operation will return all documents in the ``inventory``
-  collection where the value of the ``type`` field is ``food``.
+  collection where the value of the ``type`` field is ``'food'``.
 
 - A project can explicitly include several fields. In the following
   operation, :method:`find() <db.collection.find()>` method returns
   all documents that match the query as well as ``item`` and ``qty``
-  fields. The results also include the ``_id``, implicitly:
+  fields. The results also include the ``_id`` field:
 
   .. code-block:: javascript
 
@@ -274,7 +271,7 @@ Consider the following projection specifications, in :method:`find()
      db.inventory.find( { type: 'food' }, { type:0 } )
 
   This operation returns all documents where the value of the ``type``
-  field is ``food``, but does not include the ``type`` field in the
+  field is ``'food'``, but does not include the ``type`` field in the
   output. 
 
   With the exception of the ``_id`` field you cannot combine inclusion
@@ -324,7 +321,7 @@ Measuring Index Use
 ~~~~~~~~~~~~~~~~~~~
 
 The :method:`explain() <cursor.explain()>` cursor method allows you to
-introspect the operation of the query system, and is useful for
+inspect the operation of the query system, and is useful for
 analyzing the efficiency of queries, and for determining how the query
 uses the index. Call the :method:`explain() <cursor.explain()>` method
 on another method that returns a cursor, as in the following example: 
@@ -341,7 +338,7 @@ on another method that returns a cursor, as in the following example:
    plans, it does not reflect accurate query performance.
 
 If the above operation could not use an index, the output of
-:method:`explain() <cursor.explain()>`, would resemble the following:
+:method:`explain() <cursor.explain()>` would resemble the following:
 
 .. code-block:: javascript
 
@@ -414,7 +411,7 @@ the query used an index. This query:
   the :data:`nscannedObjects` field.
 
   This indicates that the query was not "covered," or able to complete
-  only using the index, as reflected in the :data:`indexOnly` See
+  only using the index, as reflected in the :data:`indexOnly`. See
   :ref:`indexes-covered-queries` for more information.
 
 .. index:: query optimizer
@@ -439,7 +436,7 @@ To create a new query plan, the query optimizer:
    If an index returns a result already returned by another index, the
    optimizer skips the duplicate match.
 
-#. determines a "winning" index when either of the following occur:
+#. selects an index when either of the following occur:
 
    - The optimizer exhausts an index, which means that the index has
      provided the full result set. At this point, the optimizer stops
@@ -449,8 +446,16 @@ To create a new query plan, the query optimizer:
      chooses the index that has provided the most results *first* and
      continues reading only from that index.
 
-The "winning" index becomes the index specified in the query plan:
-future iterations of this query will use this index.
+The selected index becomes the index specified in the query plan;
+future iterations of this query or queries with the same query
+pattern will use this index. Query pattern refers to query select
+conditions that differ only in the values, as in the following two
+queries with the same query pattern:
+
+.. code-block:: javascript
+
+   db.inventory.find( { type: 'food' } )
+   db.inventory.find( { type: 'utensil' } )
 
 To manually compare the performance of a query using more than one
 index, you can use the :method:`explain() <cursor.explain()>` method
@@ -459,15 +464,15 @@ following prototype:
 
 .. code-block:: javascript
 
-   db.colection.find().explain().hint()
+   db.collection.find().explain().hint()
 
 The following operations each run the same query but will reflect the
 use of the different indexes: 
 
 .. code-block:: javascript
 
-   db.collection.find( { type: 'food' } ).explain().hint( { type: 1 } )
-   db.collection.find( { type: 'food' } ).explain().hint( { type: 1, name: 1 })
+   db.inventory.find( { type: 'food' } ).explain().hint( { type: 1 } )
+   db.inventory.find( { type: 'food' } ).explain().hint( { type: 1, name: 1 })
 
 This returns the statistics regarding the execution of the query. For
 more information on the output of :method:`explain()
@@ -477,20 +482,20 @@ more information on the output of :method:`explain()
 .. note::
 
    If you run :method:`explain() <cursor.explain()>` without including
-   :method:`hint() <cursor.hint()>` the query optimizer re-evaluates
+   :method:`hint() <cursor.hint()>`, the query optimizer re-evaluates
    the query and runs against multiple indexes before returning the query
    statistics.
 
 As collections change over time, the query optimizer deletes a query
 plan and re-evaluates the after any of the following events: 
 
-- the collection recieves 1,000 write operations.
+- the collection receives 1,000 write operations.
 
 - the :dbcommand:`reIndex` rebuilds the index.
 
 - the :program:`mongod` process restarts.
 
-The order that MongoDB returns documents depend on the index used to
+The order that MongoDB returns documents depends on the index used to
 support the query. If you issue a query successive times and the data
 hasn't changed, the query will return the same results in the same
 order. However, in some cases MongoDB may return results in a
@@ -502,21 +507,21 @@ For more information, see :doc:`/applications/indexes`.
 Query Operations that Cannot Use Indexes Effectively
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Some query operations cannot use indexes effectively, or cannot use
+Some query operations cannot use indexes effectively or cannot use
 indexes at all. Consider the following situations: 
 
-- The inequality operators :operator:`$nin` and :operator:`$ne`, are
+- The inequality operators :operator:`$nin` and :operator:`$ne` are
   not very selective, as they often match a large portion of the
   index.
 
-  As a result, in most cases a :operator:`$nin` or :operator:`$ne`
+  As a result, in most cases, a :operator:`$nin` or :operator:`$ne`
   query with an index may perform no better than a :operator:`$nin` or
   :operator:`$ne` query that must scan all documents in a collection.
 
-- Queries that use specify regular expressions, with inline JavaScript
-  regular expressions or :operator:`$regex` operations cannot use an
-  index *unless* the regular expression is anchored to the beginning
-  or end of a string.
+- Queries that specify regular expressions, with inline JavaScript
+  regular expressions or :operator:`$regex` operator expressions,
+  cannot use an index *unless* the regular expression is anchored to
+  the beginning or end of a string.
 
 .. _read-operations-aggregation:
 
@@ -527,7 +532,7 @@ Aggregation
 
 MongoDB can perform some basic data aggregation operations on results
 before returning data to the application. Running aggregation
-operations on the database sides can be more efficient than running
+operations on the database side can be more efficient than running
 them in the application layer and can reduce the amount of data
 MongoDB needs to send to the application. These aggregation operations
 include basic grouping, counting, and even processing data using a map
@@ -586,18 +591,18 @@ data set among a cluster of program:`mongod` in a way that is nearly
 transparent to the application. See the :doc:`/sharding` section of
 this manual for additional information about these deployments.
 
-For a sharded clusters, issue all operations to one of the
+For a sharded cluster, you issue all operations to one of the
 :program:`mongos` instances associated with the
 cluster. :program:`mongos` instances route operations to the
 :program:`mongod` in the cluster and behave like :program:`mongod`
 instances to the application. Read operations to a sharded collection
-in a sharded are largely the same as operations to a :term:`replica
+in a sharded cluster are largely the same as operations to a :term:`replica
 set` or :term:`standalone` instances. See the section on :ref:`Read
 Operations in Sharded Clusters <sharding-read-operations>` for more
 information.
 
-In sharded deployments, the :program:`mongos` instance routes routes
-the queries from the clients to the :program:`mongod` instnaces that
+In sharded deployments, the :program:`mongos` instance routes
+the queries from the clients to the :program:`mongod` instances that
 hold the data, using the cluster metadata stored in the :ref:`config
 database <sharding-config-server>`.
 
@@ -630,7 +635,7 @@ You can configure the :ref:`read preference mode
 per-operation basis to allow reads from :term:`secondaries
 <secondary>` for backup operations, or to allow reads during
 :ref:`failover <replica-set-failover>` situations. If the majority of
-database use are read operations and, then using read preferences to
+database use are read operations, then using read preferences to
 distribute reads can improve read throughput.
 
 Read operations from secondary members of replica sets are not