Working with Indexed Assocations
This feature is scheduled for version 2.1 of Doctrine and not included in the 2.0.x series.
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
was used. Starting with Doctrine 2.1 you can index your collections by a value in the related entity.
This is a first step towards full ordered hashmap support through the Doctrine ORM.
The feature works like an implicit
INDEX BY for the selected association but has several
- 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.
- 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.
As an example we will design a simple stock exchange list view. The domain consists of the entity
Market where each Stock has a symbol and is traded on a single market. Instead of having a numerical
list of stocks traded on a market they will be indexed by their symbol, which is unique across all markets.
Mapping Indexed Assocations
You can map indexed assocations by adding:
indexByattribute to any
index-byattribute to any
<many-to-many />xml element.
indexBy:key-value pair to any association defined in
oneToMany:YAML mapping files.
The code and mappings for the Market entity looks like this:
addStock() method you can see how we directly set the key of the association to the symbol,
so that we can work with the indexed assocation directly after invoking
we pick a stock traded on the particular market by symbol. If this stock doesn't exist an exception is thrown.
Stock entity doesn't contain any special instructions that are new, but for completeness
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, that makes use of the indexing.
First we will populate our database with two example stocks traded on a single market:
<?php // $em is the EntityManager $market = new Market("Some Exchange"); $stock1 = new Stock("AAPL", $market); $stock2 = new Stock("GOOG", $market); $em->persist($market); $em->persist($stock1); $em->persist($stock2); $em->flush();
This code is not particular interesting since the indexing feature is not yet used. In a new request we could now query for the market:
<?php // $em is the EntityManager $marketId = 1; $symbol = "AAPL"; $market = $em->find("Doctrine\Tests\Models\StockExchange\Market", $marketId); // Access the stocks by symbol now: $stock = $market->getStock($symbol); echo $stock->getSymbol(); // will print "AAPL"
Market::addStock() in combination with
indexBy allows 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.
<?php // $em is the EntityManager $marketId = 1; $symbol = "AAPL"; $dql = "SELECT m, s FROM Doctrine\Tests\Models\StockExchange\Market m JOIN m.stocks s WHERE m.id = ?1"; $market = $em->createQuery($dql) ->setParameter(1, $marketId) ->getSingleResult(); // Access the stocks by symbol now: $stock = $market->getStock($symbol); 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
LAZY or EXTRA_LAZY.
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 implemeted for One-To-Many associations, because they are never the owning side.