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

Merge pull request #6800 from ErikJson/master

Browse Source 
Fix some grammar and outdated information in docs
This commit is contained in:
Andreas 2017-10-29 05:53:58 +01:00 committed by GitHub
commit ed86ee2567
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
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:: .. 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 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`` 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: downsides also:
- You have to manage both the key and field if you want to change the index by field value. - 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. - 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, it only exists for accessing purposes. - 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 - 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. with the same index-by field value is undefined.
@ -164,8 +164,6 @@ here are the code and mappings for it:
private $id; 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) * @Column(type="string", unique=true)
*/ */
private $symbol; private $symbol;
@ -227,7 +225,7 @@ here are the code and mappings for it:
Querying indexed associations 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. that makes use of the indexing.
First we will populate our database with two example stocks traded on a single market: 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" 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. 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. 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" 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 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 indexed associations also work with the ``Collection::slice()`` functionality, even if the association's fetch mode is
LAZY or EXTRA_LAZY. LAZY or EXTRA_LAZY.
Outlook into the Future 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 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>`_ 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.