Всем привет. Интересная задачка.
Есть такая схема.
Объект А
Джанкш объект Б
Объект А
Джанкш объект Б
Объект А
Джанкш объект Б
Объект А
Джанкш объект Б
Объект А
и т.д
Тоесть Объект А соединяется с друг с другом через Джанкш объект Б.
Мы находимя на верхнем уровне. Вниз может идти давольно много уровней.
Как получить это все дерево и не упасть по лимитам?
Либо доставать все записи и строить дерево рекурсивно - лимит простой - 50000 записей или heapsize. Если у тебя дерево не будет содержать больше пары тысяч элементов - то это не проблема.
Можно делать это асинхронно - показывать свернутое дерево с элементами верхнего уровня, а при открытии ветки кверить ветку (на один уровень вниз) и так дальше в глубь.
Если данные относительно статичные - дерево меняется раз в 100 лет, то можно замутить какой нибудь батч для построения дерева в виде json, сохранить и использовать его, а не тянуть каждый раз все данные.
Данные все время меняются. Их может быть более 1000000. "Дерево" это образное слово, имееся в виду получить иерархию. Да бонально получить все id Объект А с верхнего уровня вниз.
Тогда только асинхронное получение уровней подойдет.
я из этой схемы понял только то что это какой-то пздц
простыми словами - не понял ничего
У тебя, по ходу, все упирается в 100 SOQL запросов (т.е. ты вычитал первый объект, взял его ID, читаешь следующий с этим ID, берешь следующий ID и читаешь для него). Ну вложенность больше 50 - это перебор. Думаю, не стоит такое скопом пытаться выгрузить и тем более показывать.
согласен, рекурсивный подход тут будет самым оптимальным - вряд ли ты пользователь захочет просматривать более 50 уровней вложенности. учитывая что на каждом уровне ты будешь запрашивать связи ко списку идентификаторов на текущем уровне, то в лимиты ты должен влезть.
плюс. вряд ли ты будешь визуализировать это в vf - проще юзать одну из кучи js-библиотек и лучше уж юзать lazy load, нежели грузить весь скоп.
А может кто нить спросит - какая задача стоит?
Вдруг человек подошел к решению не стой стороны?
Рекурсивно у меня и было выстрено, а вложеность была большая. Плюс надо у дочернего элемента могут быть несколько родительских(тоесть могли два дерева сходится в какомто месте) и надо пересчитывать филды от этого. Тоесть по сути сделать все так как заказчик захотел можно сказать невозможно.
Пришли к решению что это будет делать батч и считать по одному уровню вниз(плюс адейтить записи). Долго, зато выполнит задачу. Проблема из-за кривого бизнес процесса, который делали без учета лимитов SF.
