Question

I was recently reading the Doctrine 2‘s best practices and was stopped by this:

25.3. Avoid composite keys
Even though Doctrine fully supports composite keys it is best not to use them if possible. Composite keys
require additional work by Doctrine and thus have a higher probability
of errors.

What I don’t get is this: if "Doctrine fully supports composite keys", how can it make mistakes when dealing with such keys?

Therefore I would like to ask this question as a community wiki, hoping it will help us understand what the "probability of errors" are:

Do you have examples to share showing situations you’ve ran into whereby Doctrine 2 was not handling composite keys well/as it should?

Answer 1

For my part I believe I’ve already ran into some issues with a very basic database schema containing a table which primary key is composed of 2 foreign keys:

When I generate my models, the entity corresponding to the product_i18n entity isn’t created:

$ php doctrine-module.php orm:convert-mapping --namespace="Dbi\Entity\\" \
--from-database --force annotation module/Dbi/src/
Processing entity "Dbi\Entity\Locale"
Processing entity "Dbi\Entity\Product"

$ php doctrine-module.php orm:generate-entities --generate-annotations=1 \
module/Dbi/src
Processing entity "Dbi\Entity\Locale"
Processing entity "Dbi\Entity\Product"

Yet, I believe my database schema was properly created:

  PRIMARY KEY (`product_id`, `locale_id`) ,
  INDEX `fk_product_i18n_locale` (`locale_id` ASC) ,
  INDEX `fk_product_i18n_product` (`product_id` ASC) ,
  CONSTRAINT `fk_product_i18n_locale`
    FOREIGN KEY (`locale_id` )
    REFERENCES `mydb`.`locale` (`id` ),
  CONSTRAINT `fk_product_i18n_product`
    FOREIGN KEY (`product_id` )
    REFERENCES `mydb`.`product` (`id` )

Also, Doctrine 2‘s Schema Manager shows that Doctrine seems to understand that relation perfectly (var_dump output altered to make it more concise: removing things such as array, RECURSION, string…):

$em = $this->getServiceLocator()->get('doctrine.entitymanager.orm_default');
$sm = $em->getConnection()->getSchemaManager();
var_dump($sm->->listTables());

object(Doctrine\DBAL\Schema\Table)#290 (10) {
["_name":protected]=> "product_i18n"

["_indexes":protected]=>
  ["primary"]=>
    ["_columns":protected]=>
      [0]=> "product_id"
      [1]=> "locale_id"

["_fkConstraints":protected]=>
  ["fk_product_i18n_locale"]=>
  object(Doctrine\DBAL\Schema\ForeignKeyConstraint)#285 (9) {
    ["_localColumnNames":protected]=> "locale_id"
    ["_foreignTableName":protected]=> "locale"
    ["_foreignColumnNames":protected]=> "id"

  ["fk_product_i18n_product"]=>
  object(Doctrine\DBAL\Schema\ForeignKeyConstraint)#286 (9) {
    ["_localColumnNames":protected]=> "product_id"
    ["_foreignTableName":protected]=> "product"
    ["_foreignColumnNames":protected]=> "id"

Therefore I’m in a situation whereby I can query the schema for the product_i18n table, but can’t interact with that table because the corresponding entity model wasn’t generated.

UPDATE: as user1136666 pointed out: the known issues and limitations page odes state the following:

Although we state that we support composite primary keys that does not
currently include foreign keys as primary key columns.

The workaround is to define a surrogate key and add a unique constraint on the foreign keys, like so:

CREATE  TABLE IF NOT EXISTS `mydb`.`product_i18n` (
  `id` INT NOT NULL AUTO_INCREMENT ,
  `name` VARCHAR(45) NULL ,
  `description` TEXT NULL ,
  `created_at` DATETIME NULL ,
  `modified_at` DATETIME NULL ,
  `product_id` INT NOT NULL ,
  `locale_id` INT NOT NULL ,
  INDEX `fk_product_i18n_locale` (`locale_id` ASC) ,
  INDEX `fk_product_i18n_product` (`product_id` ASC) ,
  PRIMARY KEY (`id`) ,
  UNIQUE (`locale_id` , `product_id`),
  CONSTRAINT `fk_product_i18n_locale`
    FOREIGN KEY (`locale_id` )
    REFERENCES `mydb`.`locale` (`id` )
  CONSTRAINT `fk_product_i18n_product`
    FOREIGN KEY (`product_id` )
    REFERENCES `mydb`.`product` (`id` )
ENGINE = InnoDB;

Feature request: http://www.doctrine-project.org/jira/browse/DDC-1926