у меня это не получается потому что orm вставляет группировку по полю id, типа она в select есть потому что. Но у меня там еще куча полей и мне не нужно по этим полям группировать ! Как мне решить мою проблему ?
Важное правило: Если в выборке есть агрегация или группировка (агрегация по уникальному значению) хотя бы для одной колонки, то все остальные колонки из SELECT и ORDER BY должны быть так же агрегированы или сгруппированы.
Андрей Николаев написал: Не использовать ORM для подобной выборки.
Там у меня очень сложный запрос. С ~5 join. генерировать самому такой запрос конечно вариант , но по моему это очень трудоемко получится. Предпологается что фильтры будут всякие разные.
Понял, что простого решения этой проблемы нету , безкостыльного. Если уж костыль делать, я тогда сделал попроще
Унаследовался от Bitrix\Main\Entity\Query; Переопределил метод buildGroup(). Скопировал код с оригинала и закакомментил строку
Код
class MyQuery extends Bitrix\Main\Entity\Query
{
protected function buildGroup()
{
...
elseif (!$chain->hasAggregation() && !$chain->hasSubquery())
{
// skip subqueries and already aggregated
//$this->registerChain('group', $chain);
}
...
}
}
В моей сущности (унаследованной от Bitrix\Main\Entity\DataManager), переопределил статичные метод query
Код
public static function query()
{
return new MyQuery(static::getEntity());
}
И все ок сразу стало. И в ядро не залез и костыль работает только для конкретной сущности, и трудоемкости на пару строк кода + простота. Остается надеяться, что изменений в классе Bitrix\Main\Entity\Query не будет серьезных, так что бы buildGroup переписали.
ЗЫ что бы избежать проблем обновления Bitrix\Main\Entity\Query::buildGroup можно модифицировать то что он отдает, такое попробовать провернуть
Андрей Николаев написал: Не использовать ORM для подобной выборки.
Там у меня очень сложный запрос. С ~5 join. генерировать самому такой запрос конечно вариант , но по моему это очень трудоемко получится. Предпологается что фильтры будут всякие разные.
Понял, что простого решения этой проблемы нету , безкостыльного. Если уж костыль делать, я тогда сделал попроще
Унаследовался от Bitrix\Main\Entity\Query; Переопределил метод buildGroup(). Скопировал код с оригинала и закакомментил строку
Код
class MyQuery extends Bitrix\Main\Entity\Query
{
protected function buildGroup()
{
...
elseif (!$chain->hasAggregation() && !$chain->hasSubquery())
{
// skip subqueries and already aggregated
//$this->registerChain('group', $chain);
}
...
}
}
В моей сущности (унаследованной от Bitrix\Main\Entity\DataManager), переопределил статичные метод query
Код
public static function query()
{
return new MyQuery(static::getEntity());
}
И все ок сразу стало. И в ядро не залез и костыль работает только для конкретной сущности, и трудоемкости на пару строк кода + простота. Остается надеяться, что изменений в классе Bitrix\Main\Entity\Query не будет серьезных, так что бы buildGroup переписали.
ЗЫ что бы избежать проблем обновления Bitrix\Main\Entity\Query::buildGroup можно модифицировать то что он отдает, такое попробовать провернуть
Придумал как без переопределения и наследования закостылить У вас получиться примерно так:
Код
$subQuery = new \Bitrix\Main\Entity\Query(Price\ValuesTable::getEntity());
$rs = Price\ValuesTable::getList([
'filter' => [
'packing_id' => [50, 60]
],
'sel ect' => array('*'),
'filter' => [
'packing_id' => new \Bitrix\Main\DB\SqlEx * pression('(SELECT t.packing_id (SELECT pe.packing_id, MAX(pe.value) FR OM '.$subQuery->getEntity()->getDBTableName().' pe WHERE pe.packing_id = '.strtolower($subQuery->getEntity()->getCode()).'.packing_id) t)')
]
]);
редактор битры маскирует код, 'SqlEx * pression' = SqlExpression