Tables with composite primary keys, or tables where a PK is also an FK, are not dumped by the sfPropelData::dumpData() method.
The source of the problem seems to be the handling of PKs and FKs in this part of sfPropelData (r2730, starting at line 298):
if ($column->isPrimaryKey())
{o
$pk .= '_' .$rs->get($col);
continue;
}
else if ($column->isForeignKey())
{
$relatedTable = $this->maps[$table]->getDatabaseMap()->getTable($column->getRelatedTableName());
$dumpData[$table][$table.$pk][$col] = $relatedTable->getPhpName().'_'.$rs->get($col);
}
else
{
$dumpData[$table][$table.$pk][$col] = $rs->get($col);
}
Changing this will require changing the corresponding part of the loadData() method as well.
Parsing composite PKs back from the current dump format might be ambiguous. At the moment, the PK is appended to the class name after an underscore in the YML file. since PKs and class names can contain underscores, extracting composite PKs from the current dump format would not be possible in these cases.
