Description: ------------ When working with foreign keys, Reverse:getTableConstraintDefinition() fails for valid foreign keys returned from Manager:listTableConstraints(), where the constraint name is not the same as the column name being constrained. Basically, the current code is making an incorrect assumption that the constraint names always match the columns with which they are associated. Test script: --------------- Consider a table: CREATE TABLE mytable (mycol int, CONSTRAINT foo FOREIGN KEY (mycol) REFERENCES othertable (othertablecolumn)); In this case, the constraint name is "foo". This is (correctly) returned by Manager:listTableConstraints(). Expected result: ---------------- Reverse:getTableConstraintDefinition('foo') returns the fully-formed constraint for the column "mycol". Actual result: -------------- Reverse:getTableConstraintDefinition('foo') fails with a "not found" error, because getTableConstraintDefinition() first does a "SHOW INDEX", and the results of SHOW INDEX show column names, not constraint names.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.