Всем привет,
как известно пагинациия списка записей важная и большая тема. Важная потом что это именно тот момент когда нам приходится думать сразу о нескольких лимитах, и большая т.к. существует несколько методов пагинации, и у каждого есть свои недостатки и достоинства. Для начала коротко перечислю их, вы добавляйте:
1. Фронт -энд пагинация:
1.1 Косметическая (фейк-пагинация) - через JS плагин, по факту весь список вываливается на страницу со всеми вытекающими.
1.2 Истинная - через РЕСТ апи, веб-сервисы или ремоут-экшинс.
2. Бек-энд пагинация:
1.1 на OFFSET-е.
1.2 на стандартном лист контроллере (по факту это тоже фейк-пагинация т.к. все записи одним махом забираются в переменную типа СтандКонтролера которая идет прямиком в СтатВью со всеми вытекающими).
1.3 полностью кастомная пагинация на переменной-счетчике.
и при выборе нужно идти от простого варианта к сложному учитывать такие факторы как РидОнли возможность и сколько максимально можно получить в список записей, в некоторых случаях все просто, так как выбираемых записей по их природе не может больше небольшого количества.
ну и вопрос в студию:
есть ли у вас какой то алгоритм принятия решения при выборе метода пагинации, логическая схема с ключевыми вопросами/моментами, которые нужно принять во внимание при выборе, чтобы прийти к полностью подходящему и при этом самому простому решению пагинации?
Ни в коем случае! Нельзя сделать OFFSET после 2000 записей, что делает его абсолютно безполезной ерундой
https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_offset.htm
Для пагинации в SF всегда используется StandardSetController (тут тоже есть по OFFSET, но лучше это проигнорить)
https://developer.salesforce.com/page/Paginating_Data_for_Force.com_Applications
Всегда фронтэнд. И не важно как вы получаете записи все сразу или пачками. И соответственно сортировка по полям выборки.
Когда я разбирался с пангинацией пришел к выводу что лучше чем StandardSetController нету,хотя там есть не плохая альтернатива.
StandardSetController для него отрабатывает DataBaseQueryLocator который может вернуть до 50 милионов, я так понимаю что он еще не кушает heap size, но 10 000 записей это ограничение для работы с одним сетом,Я еще видел статью где реализовывали интерфейс iterator для пангинации но смысла большого в этом не увидел.
а view state не свалится ? или туда поподают только переменные апекса?
=)
=)
=)
В viewstate это засоленное сериализованное состояние контроллера.
Если ты делаешь веб сервис, то состояние естественно нигде не хранится.
это я понимаю можно написать transient для листа и не боятся рендера, я про то что если одновременно придет больше количество данных не станели плохо ? Зная wilder он может сказать что это надо засунуть var js переменную и спокойно по ней ходить.
Web service если не ошибаюсь api кушают если поднимать из Js queryMOre,в задаче про это ничего не было.
Кстати про web-service возвращаясь к твоей статья я правильно понимаю что твоё решение работает,прямо прямо пропорционально тому количеству страниц которое может сгенерить salesforce server в 24 часа? то есть примерно около миллион cтарниц в сутки или там еще от лицензий зависит ?
Ну это все зависит, как ты его реализуешь?
Ну если у клиента слабый комп, то, возможно, и станет.
Если это Rest то вроде не кушает. Тем более они щас исправили косяк с субдоменами.
И кстати всегда можно замутить rest вебсервис по технологии Gres'a точно ничего не кушает :)
Понятно что не через SOAP, хотя мне кто-то рассказывал что есть js бибилиотека вроде TKRemoteJs которая апи salesforce не кушает. Насчет рест не знал что не кушает апи.
Клиенту я наверное бы постремался такое предлагать,вот вопрос вебсервис по технологии Gres'a Работает пропорционально количеству страниц которое отдает salesforce server в 24 часа ?
На счет пагинации. Я за фронтенд вариант от wilder - получать все данные на js стороне и уже по ним бегать.
Но с небольшим дополнением. В случае ОЧЕНЬ больших выборок я делаю ограничение и поиск на бэкенд стороне apex.
Я уже про это писал много раз на форуме. Пользователю нафиг не нужно пагинация по 10 000 или даже 1 000 000 записей - заи(устанет) пагинировать. Я достаю 1000 записей на страницу - делаю фронтенд пагинацию и честно предупреждаю пользователя что выборка ограничена 1000 записями и надо уточнить критерии поиска. PROFIT
ну если у фронт-эрд пагинации столько серьезных сторонников, то попробую более подробно разложить эти методы по группам:
Синхронная:
(1) выгружай все записи на страницу, а там пагинируй косметическим пагинатором (лимиты 1000 и СтайтВью - но если ограниченная по возможному количеству природа записей позволяет, то сойдет для сельской местности);
Асинхронная:
(вариант с Аджакс перерисовкой секции не разбирается, так как это просто вариант бек-энд пагинации)
(1) на ремоут экшенс, удобно, весь вопрос действуют ли здесь лимиты 1000 и СтайтВью, но думаю, что нет:
(1-1) подавай все записи на страницу а там пагинируй косметическим пагинатором;
(1-2) истинная пагинация с помощью кверения записей пачками, и здесь снова к вопросу, а как обеспечивается квериние пачками на сервере.
(2) на РЕСТ-апи (есть свои лимиты), веб-сервисах (вероятно есть свои лимиты), РЕСТ страницах Греса:
(2-1) подавай все записи на страницу а там пагинируй косметическим пагинатором, можно легко выложить тысячи записей, но идет приличная загрузка браузера, но кого это волнует...
(2-2) истинная пагинация с помощью кверения записей пачками, и здесь снова к вопросу, а как обеспечивается квериние пачками на сервере.
вспомогательный костыль: рубить список ЛИМИТ топором: просто, надежно, но мне почему то не нравится.
вариант решения проблемы длинного списка: создать в квери обязательные условия, ограничивающие кол-во выводимых записей, например только по месяцам и никак не за год.
кстати, заметил, что вы не рассматриваете варианты, и у вас нет алгоритма выбора, а просто всегда пользуетесь всегда одним и тем же методом.
Используем то что работает и проверено не один раз :)
Зачем какой-то алгоритм использовать? Делай то что работает.
