все там описано

для collectionOperations да, но как быть в случае itemOperations?

Господа, злостный оффтоп. В связи со всякой херней происходящей с ISPManager я перетаскиваю VDS на CPanel. Пойдёт ли Cloud версия на железе хетцнеровском?

А как в доктрине можно отключить оптимизацию запросов через queryBuilder? Делать один прямой запрос без count(DISTINCT) и т.д.

что значит прямой запрос?) тут походу у вас пагинатор

Да тут есть пагинатор, но и без него тоже доктрина "оптимизирует запросы".
Я делаю запрос типо "SELECT * FROM admin LIMIT 10", вот что-бы сразу его и делать а не запрашивать ид перед этим

ну нет)

само оно такое не делает) тока пагинация, берет кол-во уникальных id и подставляет в where in

distinct - если есть join в запросн

Возможно, не буду сейчас спорить про это. Но как-то можно на определённом запросе отключить такое?

интересно, что тебя сподвигло заблюрить поля? читать невозможно!

злые хацкеры тут сидят, и ждут как взломать твой суперпроект, по названию поей и таблиц

Можно попробовать query поставить в false хинт CountWalker::HINT_DISTINCT

но опять же, это при пагинации)

используй dbal и не будет проблем с лишними запросами

ребят, посоветуйте по вопросу тестов, есть apiplatform, хочу юнит тесты написать пока кода немного, но не понятно как поступить с фикстурами и чистой бд.
я хочу чтобы каждый мог локально у себя тесты запустить и чтобы текущая бд сохранилась.
я подумал может создать скрипт который
1) поднимал бд в докере
2) накатывал миграции
3) создавал там фикстуры
4) тестил
5) выпиливал её
насколько такой подход вообще адекватный? может получше практики есть?

с бд - это не юнит тесты, а интеграционные

нормальный подход иметь тестинг конфиг для приложения, который будет конектится к другой БД
перед стартом тестов накатываются миграции
каждый тест накатывает свои фикстуры и после теста чистит базку за собой

нашел, спасибо, попробую разобраться

а вот если эту другую бд создавать прямо перед тестами в контейнере скриптом, это норм?