Skip to content


Subversion checkout URL

You can clone with
Download ZIP
branch: 2.0.x
Fetching contributors…

Cannot retrieve contributors at this time

299 lines (230 sloc) 10.106 kb

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 INDEX BY 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 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.
  • 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 Stock and 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:

  • indexBy attribute to any @OneToMany or @ManyToMany annotation.
  • index-by attribute to any <one-to-many /> or <many-to-many /> xml element.
  • indexBy: key-value pair to any association defined in manyToMany: or oneToMany: YAML mapping files.

The code and mappings for the Market entity looks like this:

Inside the 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 addStock(). Inside getStock($symbol) we pick a stock traded on the particular market by symbol. If this stock doesn't exist an exception is thrown.

The 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:

// $em is the EntityManager

$market = new Market("Some Exchange");
$stock1 = new Stock("AAPL", $market);
$stock2 = new Stock("GOOG", $market);


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:

// $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"

The implementation 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.

// $em is the EntityManager
$marketId = 1;
$symbol = "AAPL";

$dql = "SELECT m, s FROM Doctrine\Tests\Models\StockExchange\Market m JOIN m.stocks s WHERE = ?1";
$market = $em->createQuery($dql)
             ->setParameter(1, $marketId)

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

Jump to Line
Something went wrong with that request. Please try again.