From 302c3a6640d57ab86df61b63e2581a31b2c5a557 Mon Sep 17 00:00:00 2001 From: Erik Johansson Date: Sun, 29 Oct 2017 00:26:25 +0300 Subject: [PATCH] Fix some grammar and outdated information in docs --- .../working-with-indexed-associations.rst | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/docs/en/tutorials/working-with-indexed-associations.rst b/docs/en/tutorials/working-with-indexed-associations.rst index 3536a34f8..a62d8b342 100644 --- a/docs/en/tutorials/working-with-indexed-associations.rst +++ b/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 `_ -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.