Bitrix ORM «правильный» getList с OneToMany?

Question

[Дмитрий Игошев]

Пытаюсь собрать "правильный" getList.
Есть 2 сущности связанные через OneToMany и Reference с другой стороны (связь множественная).
Делаю выборки getList()->fetch()/->fetchAll()/->fetchCollection();
Все хорошо пока в запрос не добавляется limit.
Если у сущности 2 связанных элемента то на нее будет "потрачено" 2 "лимита". И не важно каким образом будет обработан результат.
Грубо говоря если у первого элемента будет 2 дочерних то в выборку попадут 4 строки вместо 5ти (2 строки ушли на первых элемент).

Я смог собрать запрос при помощи ExpressionField и fetch_data_modification. Суть тут заключается в том что я динамически собираю id дочерних элементов в строку, а затем в fetch_data_modification доп запросом получаю эти объекты.
С таким костылем limit работает корректно но: 1) это плохо пахнет, 2) функцию модификации придется писать ко всем связанным сущностям.

Как это делать правильно? Оно вообще умеет правильно работать с limit и OneToMany одновременно?

Пример getList

$arSelect   =   [
	'*',
    'SPECIALIZATION'
];
$arOrder    =   ['ID'=>'ASC'];
$limit      =   2;

$obResult   =   \K\Core\User\VerificationTable::getList([
    'select'=>  $arSelect,
    'order' =>  $arOrder,
    'limit' =>  $limit
])->fetchCollection();

echo count($obResult);

Результатом будет 1, а не 2.

Маппинг базовой сущности VerificationTable

public static function getMap():array{
		return  [
			(new Entity\IntegerField('ID'))
				->configurePrimary()
				->configureAutocomplete(),
			(new OneToMany(
				'SPECIALIZATION',
				'\K\Core\User\Verification\SpecializationTable',
				'VERIFICATION'
			)),
		];
	}

Маппинг подчиненной сущности SpecializationTable

public static function getMap():array{
		return  [
			(new Entity\IntegerField('ID'))
				->configurePrimary()
				->configureAutocomplete(),
			(new Entity\IntegerField('VERIFICATION_ID'))
				->configureRequired(),
			(new Entity\ReferenceField('VERIFICATION',
				'\K\Core\User\VerificationTable',
				['=this.VERIFICATION_ID'=>'ref.ID']
			))->configureTitle(self::getMessage('K_CORE_FIELD_VERIFICATION_TITLE')),
		];
	}

Comments

[Алексей Емельянов]

1. Приложите код, хотя бы getList
2. Зачем limit задавать прям так впритык?

а затем в fetch_data_modification доп запросом получаю эти объекты

- уверен что создатели fetch_data_modification даже не предполагали что так можно юзать)

[PetrPo]

Действительно, очень неожиданый результат. Но уж лучше два запроса сделай, чем извращение с fetch_data_modification

[Дмитрий Игошев]

Алексей Емельянов, обновил тело вопроса, приложил getList и маппинги сущностей.
limit - я указал для примера какая разница 1 или 100 если финальное количество записей плавает?
fetch_data_modification - документация говорит что это колбэк функция форматирования данных при запросе. В самом ядре есть примеры использования этой функции для получения параметров файла (сущность не помню). В общем они и сами это пользуют.

PetrPo, проблема в универсализации - фронт хочет одним запросом получать данные из таблицы 1 + подчиненные данные. А limit с offset нужны для постранички.

[PetrPo]

Dreamod, не пойму твою мысль. Ты хочешь выбрать 10 записей "основной" сущности и все связанные с ними записи "связанной" сущности?
т.е. постраничка должна относится к 1-ой сущности = 1-ый запрос на основную сущность с лимитом 10, 2-ой запрос на связанные сущности с фильтром по id основных сущностей, без лимита.
Для универсальности добавляешь какой-то свой метод, с двумя параметрами = 1-ый для гетлиста "основной" сущности, 2-ой для гетлиста "связанной" сущности. +- возможно какие-то параметры гетлистов можно будет сделать фиксированными

[Дмитрий Игошев]

PetrPo, да я хочу поставить лимит на getList первой сущности.
Хочу получить 2 верификации и все прикрепленные ним элементы.
Результат нужен такой:

Array
(
    [0] => Array
        (
            [ID] => 1
            [USER_ID] => 5
            [SPECIALIZATION] => Array
                (
                    [0] => Array
                        (
                            [ID] => 1
                            [VERIFICATION_ID] => 1
                        )
                    [1] => Array
                        (
                            [ID] => 2
                            [VERIFICATION_ID] => 1
                        )
                )
        )
    [1] => Array
        (
            [ID] => 2
            [USER_ID] => 4
        )
)

А сейчас он такой:

Array
(
    [0] => Array
        (
            [ID] => 1
            [USER_ID] => 5
            [SPECIALIZATION] => Array
                (
                    [0] => Array
                        (
                            [ID] => 1
                            [VERIFICATION_ID] => 1
                        )
                    [1] => Array
                        (
                            [ID] => 2
                            [VERIFICATION_ID] => 1
                        )
                )
        )
)

[PetrPo]

Дмитрий Игошев, что-то типа того

$verifications = $verificationsId = [];

$select = [
  '*',
];
$order = ['ID'=>'ASC'];
$limit = 2;
$iterator = \K\Core\User\VerificationTable::getList([
    'select'=>  $select,
    'order' =>  $order,
    'limit' =>  $limit
]);

while($row = $iterator->fetch()) {
	$verificationId = $row['ID'];
	
	$verifications[$verificationId] = $row;
	$verificationsId[] = $verificationId;
}

if($verificationsId) {
	$select = [
	  '*',
	];
	$filter = [
		'VERIFICATION_ID' => $verificationsId
	];
	$order = ['ID'=>'ASC'];
	$iterator = \K\Core\User\SpecializationTable::getList([
		'select'=>  $select,
		'filter' => $filter,
		'order' =>  $order,
	]);
	
	while($row = $iterator->fetch()) {
		$verificationId = $row['VERIFICATION_ID'];
	
		if(isset($verifications[$verificationId])) {
			$verifications[$verificationId]['SPECIALIZATION'][] = $row
		}
	}
}

Объем кода конечно больше, но зато он прозрачный

[Дмитрий Игошев]

PetrPo, С 2мя запросами то все предельно ясно. Сейчас все так и работает - через простые CRUD запросы. Но где "сила" ORM?? =)
Пойду саппорт мучать

[PetrPo]

Дмитрий Игошев, ок, напиши если что-нибудь прояснится

[Дмитрий Игошев]

PetrPo, В общем нельзя так.
Хочешь limit и offset - делай 2 запроса.


Как вариант разбить на 2 запроса:
1) с limit и offset для получения ID первичных сущностей
2) с filter=['ID'=>$arId] и select=['SOME_ONE_TO_MANY_FIELD']
Это конечно не так удобно как в 1 getList, но не придется кружить с кучей доп getListов. Первым выбрал массив id, вторым выбрал результирующий массив/объект с данными.

[Дмитрий Игошев]

Дмитрий Игошев, после ряда тестов выяснил что предложенный саппортом вариант выборок единственно возможный.
Если выбирать данные из b_user limit 50 + пара смежных таблиц по oneToMany то запрос проходит за условные (конские) 20 секунд Оо. БД при этом пустая, железка холодная.
А если разбить на 2 запроса то все тоже самое запрашивается за 300мс.

Круто что в документации об этом ни слова. Оставил заявку на исправление.

Answer 1

[BookaZoid]

Мне помогло исключение поля связи из getList и далее дозаполнение его через $collection->fill(['FIELDNAME']);

Comments

[VadimGeg]

Спасибо добрый человек, тоже с этой проблемой мучился