Доктрина: выберите запрос для обновления соединения с гидратированной сущностью?

Запрос загружает и гидратирует основную сущность с ее объединенными сущностями, которые фильтруются. Тот же запрос с другой фильтрацией не обновил присоединенные объекты.

Некоторые данные:

Tiers:
| id | name  |
| 1  | alpha |
| 2  | beta  |

Container:
| id  | tiers_id | category |
| 10  | 1        | A        |
| 20  | 1        | A        |
| 30  | 1        | B        |
| 40  | 1        | B        |

Выполните 2 запроса, чтобы получить несколько уровней со своими контейнерами, сначала категория A, затем категория B:

$dql = "select t, c
    from Tiers t
    join t.containers c
    where t.id in (?1) and c.category = (?2)";

$result = $em->createQuery($dql)
    ->setParameter(1, array(1))
    ->setParameter(2, 'A')
    ->getResult();
$tiers = $result[0];
$containers = $tiers->getContainers(); // tiers 1 with containers 10 and 20, that's fine !

$result = $em->createQuery($dql)
    ->setParameter(1, array(1))
    ->setParameter(2, 'B')
    ->getResult();
$tiers = $result[0];
$containers = $tiers->getContainers(); // BAD HERE: still get containers 10 and 20, looking for containers 30 and 40.

После второго запроса уровни 1 сохраняют свои контейнеры, загруженные во время первого запроса.. Это не то, что ожидается. Так есть ли способ получить контейнеры 30 и 40 после второго запроса?
Может быть, своего рода «сбросить / отсоединить» контейнеры ярусов сущностей после первого запроса?
Или что-нибудь еще ...

Множественный выбор в запросах используется для объединения уровней с требуемыми контейнерами. Метод getContainers дает ожидаемые контейнеры для каждого уровня. А стоимость для BDD составляет всего 1 SQL-запрос, независимо от количества просматриваемых уровней.

Я полагаю, что уровни не могут быть отсоединены / перезагружены, потому что они обновляются до, между и после запросов, при сбросе возникает такое исключение:

Uncaught Exception: Multiple non-persisted new entities were found through the given association graph
* A new entity was found through the relationship 'XXX' that was not configured to cascade persist operations for entity: XXX\Entity\Tiers@00000000257b87500000000018499b62.