RetailCRM-Mirror/doctrine2
1
0
Fork 0
mirror of synced 2025-02-02 13:31:45 +03:00
Code Issues Projects Releases Wiki Activity

Fix some grammar and outdated information in docs

Browse Source
This commit is contained in:
Erik Johansson 2017-10-29 00:26:25 +03:00
parent 0497f50ba6
commit 302c3a6640
1 changed files with 8 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
docs/en/tutorials/working-with-indexed-associations.rst
View File

@ -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.