Merge pull request #6800 from ErikJson/master

Fix some grammar and outdated information in docs

docs/en/tutorials/working-with-indexed-associations.rst

@@ -3,7 +3,7 @@ Working with Indexed Associations
 
 .. note::
 
-    This feature is scheduled for version 2.1 of Doctrine and not included in the 2.0.x series.
+    This feature is available from version 2.1 of Doctrine.
 
 Doctrine 2 collections are modelled after PHPs native arrays. PHP arrays are an ordered hashmap, but in
 the first version of Doctrine keys retrieved from the database were always numerical unless ``INDEX BY``
@@ -13,8 +13,8 @@ The feature works like an implicit ``INDEX BY`` for the selected association but
 downsides also:
 
 -  You have to manage both the key and field if you want to change the index by field value.
--  On each request the keys are regenerated from the field value not from the previous collection key.
--  Values of the Index-By keys are never considered during persistence, it only exists for accessing purposes.
+-  On each request the keys are regenerated from the field value, and not from the previous collection key.
+-  Values of the Index-By keys are never considered during persistence. They only exist for accessing purposes.
 -  Fields that are used for the index by feature **HAVE** to be unique in the database. The behavior for multiple entities
    with the same index-by field value is undefined.
 
@@ -164,8 +164,6 @@ here are the code and mappings for it:
             private $id;
 
             /**
-             * For real this column would have to be unique=true. But I want to test behavior of non-unique overrides.
-             *
              * @Column(type="string", unique=true)
              */
             private $symbol;
@@ -227,7 +225,7 @@ here are the code and mappings for it:
 Querying indexed associations
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Now that we defined the stocks collection to be indexed by symbol we can take a look at some code,
+Now that we defined the stocks collection to be indexed by symbol, we can take a look at some code
 that makes use of the indexing.
 
 First we will populate our database with two example stocks traded on a single market:
@@ -263,7 +261,7 @@ now query for the market:
 
     echo $stock->getSymbol(); // will print "AAPL"
 
-The implementation ``Market::addStock()`` in combination with ``indexBy`` allows to access the collection
+The implementation of ``Market::addStock()``, in combination with ``indexBy``, allows us to access the collection
 consistently by the Stock symbol. It does not matter if Stock is managed by Doctrine or not.
 
 The same applies to DQL queries: The ``indexBy`` configuration acts as implicit "INDEX BY" to a join association.
@@ -285,8 +283,8 @@ The same applies to DQL queries: The ``indexBy`` configuration acts as implicit
 
     echo $stock->getSymbol(); // will print "AAPL"
 
-If you want to use ``INDEX BY`` explicitly on an indexed association you are free to do so. Additionally
-indexed associations also work with the ``Collection::slice()`` functionality, no matter if marked as
+If you want to use ``INDEX BY`` explicitly on an indexed association you are free to do so. Additionally,
+indexed associations also work with the ``Collection::slice()`` functionality, even if the association's fetch mode is
 LAZY or EXTRA_LAZY.
 
 Outlook into the Future
@@ -294,5 +292,5 @@ Outlook into the Future
 
 For the inverse side of a many-to-many associations there will be a way to persist the keys and the order
 as a third and fourth parameter into the join table. This feature is discussed in `DDC-213 <http://www.doctrine-project.org/jira/browse/DDC-213>`_
-This feature cannot be implemented for One-To-Many associations, because they are never the owning side.
+This feature cannot be implemented for one-to-many associations, because they are never the owning side.