Пропел много-ко-многим проблемы с гидратацией

Моя проблема в том, что я не могу гидрировать объект Propel ORM в случае отношения «многие ко многим», и даже если я выберу все из каждой таблицы с помощью find (), он все равно будет отправлять запрос в случае «многие ко многим». Многие отношения.

Я нашел много вопросов об этом здесь в stackoverflow и во многих других местах, но ни один не работает для меня. Вот тот же самый точный вопрос с принятым ответом, который также не работает для меня:
найти запрос для многих для многих отношений

Моя проблема точно такая же, только с другой схемой.

Моя схема.xml

<?xml version="1.0" encoding="utf-8"?>
<database name="propelDB" defaultIdMethod="native" defaultPhpNamingMethod="underscore" namespace="TestDB">
<table name="c_catalogs_locations" idMethod="native" phpName="CCatalogsLocations" isCrossRef="true">
<column name="catalogid" phpName="Catalogid" type="INTEGER" primaryKey="true" required="true"/>
<column name="locationid" phpName="Locationid" type="INTEGER" primaryKey="true" required="true"/>
<foreign-key foreignTable="catalogs">
<reference local="catalogid" foreign="id"/>
</foreign-key>
<foreign-key foreignTable="locations">
<reference local="locationid" foreign="id"/>
</foreign-key>
<vendor type="mysql">
<parameter name="Engine" value="InnoDB"/>
</vendor>
</table>
<table name="catalogs" idMethod="native" phpName="Catalogs">
<column name="id" phpName="Id" type="INTEGER" primaryKey="true" autoIncrement="true" required="true"/>
<column name="userid" phpName="Userid" type="INTEGER"/>
<column name="name" phpName="Name" type="VARCHAR" size="45" required="true"/>
<column name="images" phpName="Images" type="LONGVARCHAR"/>
<foreign-key foreignTable="users">
<reference local="userid" foreign="id"/>
</foreign-key>
<vendor type="mysql">
<parameter name="Engine" value="InnoDB"/>
</vendor>
</table>
<table name="locations" idMethod="native" phpName="Locations">
<column name="id" phpName="Id" type="INTEGER" primaryKey="true" autoIncrement="true" required="true"/>
<column name="location" phpName="Location" type="VARCHAR" size="45" required="true"/>
<vendor type="mysql">
<parameter name="Engine" value="InnoDB"/>
</vendor>
</table>
</database>

Запрос я пытаюсь:

$locations = \Base\LocationsQuery::create()
->join("Locations.CCatalogsLocations")
->join("CCatalogsLocations.Catalogs")
->with("Catalogs")
->find();

foreach($locations as $location)
{
echo "- " . $location->getLocation() ."<br>";
foreach($location->getCatalogss() as $catalog) {
echo "-- " . $catalog . "<br>";
}
echo "<br>";
}

(Я знаю, что имена классов не очень хорошие, но это всего лишь тестовый проект, поэтому мне было все равно.)

Ссылка на документацию, которую я использую и ищу: http://propelorm.org/documentation/
Я использую новейший пропел, клонированный из git с композитором.

Я копался в документации Propel, но я не нашел, что он точно записал, что он не может этого сделать, но я также не мог решить это с помощью методов join (), joinWith () или with ().

Я установил propel для использования «classname»: «Propel \ Runtime \ Connection \ DebugPDO», чтобы он регистрировал каждый отправленный запрос, и любой мой запрос показывает, что мои объекты не обрабатываются должным образом, и propel запускает запрос каждый раз, когда я вызываю $ location-> getCatalogss () на одной стороне соединения «многие ко многим».

Propel log:

[2014-10-17 09:25:50] propelDB.INFO: SELECT locations.id, locations.location, catalogs.id, catalogs.userid, catalogs.name, catalogs.images FROM locations INNER JOIN c_catalogs_locations ON (locations.id=c_catalogs_locations.locationid) INNER JOIN catalogs ON (c_catalogs_locations.catalogid=catalogs.id) [] []
[2014-10-17 09:25:51] propelDB.INFO: SELECT catalogs.id, catalogs.userid, catalogs.name, catalogs.images FROM catalogs INNER JOIN c_catalogs_locations ON (catalogs.id=c_catalogs_locations.catalogid) WHERE c_catalogs_locations.locationid=8 [] []
[2014-10-17 09:25:51] propelDB.INFO: SELECT catalogs.id, catalogs.userid, catalogs.name, catalogs.images FROM catalogs INNER JOIN c_catalogs_locations ON (catalogs.id=c_catalogs_locations.catalogid) WHERE c_catalogs_locations.locationid=9 [] []
[2014-10-17 09:25:51] propelDB.INFO: SELECT catalogs.id, catalogs.userid, catalogs.name, catalogs.images FROM catalogs INNER JOIN c_catalogs_locations ON (catalogs.id=c_catalogs_locations.catalogid) WHERE c_catalogs_locations.locationid=10 [] []
[2014-10-17 09:25:51] propelDB.INFO: SELECT catalogs.id, catalogs.userid, catalogs.name, catalogs.images FROM catalogs INNER JOIN c_catalogs_locations ON (catalogs.id=c_catalogs_locations.catalogid) WHERE c_catalogs_locations.locationid=13 [] []
[2014-10-17 09:25:51] propelDB.INFO: SELECT catalogs.id, catalogs.userid, catalogs.name, catalogs.images FROM catalogs INNER JOIN c_catalogs_locations ON (catalogs.id=c_catalogs_locations.catalogid) WHERE c_catalogs_locations.locationid=14 [] []
[2014-10-17 09:25:51] propelDB.INFO: SELECT catalogs.id, catalogs.userid, catalogs.name, catalogs.images FROM catalogs INNER JOIN c_catalogs_locations ON (catalogs.id=c_catalogs_locations.catalogid) WHERE c_catalogs_locations.locationid=15 [] []
[2014-10-17 09:25:51] propelDB.INFO: SELECT catalogs.id, catalogs.userid, catalogs.name, catalogs.images FROM catalogs INNER JOIN c_catalogs_locations ON (catalogs.id=c_catalogs_locations.catalogid) WHERE c_catalogs_locations.locationid=11 [] []
[2014-10-17 09:25:51] propelDB.INFO: SELECT catalogs.id, catalogs.userid, catalogs.name, catalogs.images FROM catalogs INNER JOIN c_catalogs_locations ON (catalogs.id=c_catalogs_locations.catalogid) WHERE c_catalogs_locations.locationid=12 [] []

Я вижу, что я хочу использовать запрос SELECT, который запускает сначала, поэтому он выбирает все строки Location, связанные со строками своих каталогов, но он только гидратирует местоположения, а не каталоги.
Было бы хорошо сделать это даже с помощью 2 запросов, чтобы отдельно гидрировать Locations и Catalogs или даже crossRefTable и иметь Propel для обработки объединения, но даже если я их гидратирую, но propel по-прежнему не использует свои локальные данные, но отправляет отдельный запрос ,

Я делаю что-то неправильно? Как ты решил это?
Любая идея, как решить эту проблему с помощью пользовательской гидратации, которая требует максимально возможного количества запросов (столько таблиц не существует) (они не будут огромными таблицами с большими данными, поэтому запрос всей таблицы не является проблемой, и я все равно нуждаюсь в них)