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

Closed
doctrinebot opened this Issue Apr 27, 2010 · 6 comments

2 participants

@doctrinebot

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('aid', 'bid')

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;
@doctrinebot

Comment created by romanb:

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

@doctrinebot

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

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

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

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

Issue was closed with resolution "Fixed"

@jwage jwage was assigned by doctrinebot Dec 6, 2015
@doctrinebot doctrinebot added this to the 2.0-BETA2 milestone Dec 6, 2015
@doctrinebot doctrinebot closed this Dec 6, 2015
@doctrinebot doctrinebot added the Bug label Dec 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment