The pake task "propel-dump-data" dumps data from the database into a data fixture file allowing to upgrade the database schema and loading the fixtures back into the system. However this does not work in cases when a foreign key refers to the a primary key in the same table as well as when two foreign keys located in two different tables refer each to the primary key of the other table. In these cases sfPropelData::fixOrderingOfForeignKeyData() will never exit it's recursive calls. This situation is not very uncommon; think of an employee (having a department as foreign key) and a department having a manager (wich is a foreign key to the employee table)
As far as I found out, reordering the classes was the solution of yet another problem, namely that inserting data into a table with a foreign key will fail unless the foreign table has been filled with data before. Reordering the tables might may have been a quick and dirty workaround but does not finally solve this in cases as stated above.
The real solution would be to temporarily switch off foreign key constraints, insert the data, engage foreign key constraints - no matter wich table comes first. It would be best to enclose the whole recovering process in a transaction to have all or no data in the database. Disabling the foreign keys can be either to remove them completely or - if supported by the DB engine - have them disabled during this transaction. For PostgreSQL see http://www.postgresql.org/docs/8.1/interactive/sql-set-constraints.html
