DDC-549: \Doctrine\ORM\Mapping\DatabaseDriver::loadMetadataForClass fails to detect primary key when primary key is also a foreign key #681

New Issue

admin · 2026-01-22T12:46:36+01:00

admin commented

2026-01-22 12:46:36 +01:00

Originally created by @doctrinebot on GitHub (Apr 27, 2010).

Originally assigned to: @jwage on GitHub.

Jira issue originally created by user mjh_ca:

Encoutered this error while attempting to reverse engineer a database. Was previously working with 2.0-ALPHA4 so this is the result of some change between ALPHA4 and BETA1.

The reverse engineering process fails with a Doctrine\ORM\Mapping\MappingException with message "No identifier/primary key specified for Entity mytable. Every entity must have an identifier/primary key."

This exception is thrown because the "identifier" property of the ClassMetadataInfo object passed to loadMetadataForClass is not populated with the expected value (which in this case should be array('a_id', 'b_id')

It appears that this is caused by the following code in \Doctrine\ORM\Mapping\DatabaseDriver::loadMetadataForClass():

            // Skip columns that are foreign keys
            foreach ($foreignKeys as $foreignKey) {
                if (in*array(strtolower($column->getName()), array*map('strtolower', $foreignKey->getColumns()))) {
                    continue(2);
                }
            }

The table definition is something like:

CREATE TABLE a (
  a*id BIGINT UNSIGNED NOT NULL AUTO*INCREMENT,
  PRIMARY KEY (a_id)
) ENGINE=InnoDB;

CREATE TABLE b (
  b*id BIGINT UNSIGNED NOT NULL AUTO*INCREMENT,
  PRIMARY KEY (b_id)
) ENGINE=InnoDB;

/** this is the table that fails to be reverse engineered **/
CREATE TABLE mytable (
  a_id BIGINT UNSIGNED NOT NULL,
  b_id BIGINT UNSIGNED NOT NULL,
  PRIMARY KEY (a*id, b*id),
  CONSTRAINT `a*id_ibfk` FOREIGN KEY (`a_id`) REFERENCES `a` (`a*id`),
  CONSTRAINT `b*id_ibfk` FOREIGN KEY (`b_id`) REFERENCES `b` (`b*id`),
) ENGINE=InnoDB;

Originally created by @doctrinebot on GitHub (Apr 27, 2010). Originally assigned to: @jwage on GitHub. Jira issue originally created by user mjh_ca: Encoutered this error while attempting to reverse engineer a database. Was previously working with 2.0-ALPHA4 so this is the result of some change between ALPHA4 and BETA1. The reverse engineering process fails with a Doctrine\ORM\Mapping\MappingException with message "No identifier/primary key specified for Entity `mytable`. Every entity must have an identifier/primary key." This exception is thrown because the "identifier" property of the ClassMetadataInfo object passed to loadMetadataForClass is not populated with the expected value (which in this case should be array('a_id', 'b_id') It appears that this is caused by the following code in \Doctrine\ORM\Mapping\DatabaseDriver::loadMetadataForClass(): ``` // Skip columns that are foreign keys foreach ($foreignKeys as $foreignKey) { if (in*array(strtolower($column->getName()), array*map('strtolower', $foreignKey->getColumns()))) { continue(2); } } ``` The table definition is something like: ``` CREATE TABLE a ( a*id BIGINT UNSIGNED NOT NULL AUTO*INCREMENT, PRIMARY KEY (a_id) ) ENGINE=InnoDB; CREATE TABLE b ( b*id BIGINT UNSIGNED NOT NULL AUTO*INCREMENT, PRIMARY KEY (b_id) ) ENGINE=InnoDB; /** this is the table that fails to be reverse engineered **/ CREATE TABLE mytable ( a_id BIGINT UNSIGNED NOT NULL, b_id BIGINT UNSIGNED NOT NULL, PRIMARY KEY (a*id, b*id), CONSTRAINT `a*id_ibfk` FOREIGN KEY (`a_id`) REFERENCES `a` (`a*id`), CONSTRAINT `b*id_ibfk` FOREIGN KEY (`b_id`) REFERENCES `b` (`b*id`), ) ENGINE=InnoDB; ```

admin added the Bug label 2026-01-22 12:46:36 +01:00

admin closed this issue

2026-01-22 12:46:36 +01:00

admin commented

2026-01-22 12:46:37 +01:00

@doctrinebot commented on GitHub (Apr 28, 2010):

Comment created by romanb:

That table should probably be detected to be a many-many join table (no entity).

@doctrinebot commented on GitHub (Apr 28, 2010): Comment created by romanb: That table should probably be detected to be a many-many join table (no entity).

admin commented

2026-01-22 12:46:39 +01:00

@doctrinebot commented on GitHub (Apr 28, 2010):

Comment created by @jwage:

I am not sure how we should fix this. Do you want to try and enhance the reverse engineering so it properly detects many2many reference tables? That seems like it might not work too well for most databases?

@doctrinebot commented on GitHub (Apr 28, 2010): Comment created by @jwage: I am not sure how we should fix this. Do you want to try and enhance the reverse engineering so it properly detects many2many reference tables? That seems like it might not work too well for most databases?

admin commented

2026-01-22 12:46:39 +01:00

@doctrinebot commented on GitHub (Apr 28, 2010):

Comment created by romanb:

@Jon: The report mentions this was working with ALPHA4 so I thought this is (was) already possible.

@Marc: Can you maybe elaborate on how exactly ALPHA4 did behave? Did it detect the join table as an entity or as a many-many join table?

@doctrinebot commented on GitHub (Apr 28, 2010): Comment created by romanb: @Jon: The report mentions this was working with ALPHA4 so I thought this is (was) already possible. @Marc: Can you maybe elaborate on how exactly ALPHA4 did behave? Did it detect the join table as an entity or as a many-many join table?

admin commented

2026-01-22 12:46:40 +01:00

@doctrinebot commented on GitHub (Apr 28, 2010):

Comment created by mjh_ca:

@Roman Sorry, should have been more clear. It wasn't throwing an exception in ALPHA4 as far as I recall. It may not have actually been generating correct mappings.

@Jon If reverse engineering the mapping is not possible, what about generating a class containing a comment to that effect? Or, skip the table with a warning and continue rather than throwing an exception. With an exception being thrown on the CLI, there is no way to work around it and reverse engineer the other tables.

@doctrinebot commented on GitHub (Apr 28, 2010): Comment created by mjh_ca: @Roman Sorry, should have been more clear. It wasn't throwing an exception in ALPHA4 as far as I recall. It may not have actually been generating correct mappings. @Jon If reverse engineering the mapping is not possible, what about generating a class containing a comment to that effect? Or, skip the table with a warning and continue rather than throwing an exception. With an exception being thrown on the CLI, there is no way to work around it and reverse engineer the other tables.

admin commented

2026-01-22 12:46:41 +01:00

@doctrinebot commented on GitHub (Apr 29, 2010):

Comment created by @jwage:

Ok, I suppose we need to work out something for the CLI that issues warning instead of fatal exceptions so that it can continue on building the other entities.

@doctrinebot commented on GitHub (Apr 29, 2010): Comment created by @jwage: Ok, I suppose we need to work out something for the CLI that issues warning instead of fatal exceptions so that it can continue on building the other entities.

admin commented

2026-01-22 12:46:41 +01:00

@doctrinebot commented on GitHub (May 14, 2010):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (May 14, 2010): Issue was closed with resolution "Fixed"

admin referenced this issue

2026-01-22 16:00:25 +01:00

[PR #681] [CLOSED] Sequence generator fix #8549

admin referenced this issue

2026-01-22 16:00:26 +01:00

[PR #681] Sequence generator fix #8551

Sign in to join this conversation.