Всем привет!
Решил снова поднять эту тему, так как для меня она до конца не решена.
Народу на форуме прибавилось и так что давайте обсудим это заново.
Итак квери (с пустыми по умолчанию фильтрами) возвращает список в 12к записей.
Это как-то нужно подать на фронт с пагинацией.
Вариант первый: пагинируем с помощью стандарного контролера.
Описано в блоге здесь:
https://salesforce-developer.ru/paginatsiya-na-visualforce-stranitse-pagination-using-standardsetcontroller
стандарный контролер - звучит хорошо, но "король-то голый" - переменная
идет прямиком в СтейтВью, и "ложит" лимит по его размеру: в зависимости от выкверинных полей от 1000 до 3000 записей предел.
поэтому приходится на фронте писать, что мол не пугайтесь, что указано только 2000 записей, мы не может вывести на пагинцию список более 2000 записей, применяйте фильтры выше.
а можно это как решить по-настоящему? что никаких фильтров и пагинации со списком в 12к записей?
спасибо
можно попробовать transient у переменной твоей поставить
если под твои условия подойдет, то используй
Делал както пагинацыю похожую как в сф(использовал Apex & VisualForce), но без сортировки по колонкам(Покачто есть вариант полсе которога юзера кидает на первую страницу). Сейчас работает при 30 000+ рекордах. Только кнопка "Last Page" доступна для нажатия только если записей меньше чем 2000(как в сф). На каждое нажатие "Next", "Previous" - делаю отдельный запрос в базу, чтобы витянуть записи которые нужно отображать на текущей странице, была проблема что в soql нельзя делать OFSET > 2000, пришлось не хорошо сделать, сортировка записей по ID, и запоминаю ID каждого 2000-го рекорда, и потом отфильтрофую не нужные записи по ID, так чтобы не было необходимости делать OFSET > 2000, костильно но работает. При размере страници в 30, переход происходить мгновено. Осталось только придумаю, как сделать сортировку по столбцам, так чтобы не вилететь за лимити.
ИМХО, страница не должна отображать дофигиша рекордов, я даже не могу представить, когда кому то захочеться переходить на все страници. Как по мне, должны быть фильтри, и юзер с их помощу должне находить только те записи, которые ему нужно.
Это все верно.
Но есть лист который изначально подгружается без фильтров, и админы напрягаются, говорят: а почему там только 2000 записей?! у меня же больше было!!
так что приходится писать пояснение.
ну или сразу надо какой-то фильтр использовать.
Пиши 2000+
такие вещи как пагинацию нужно разруливать в контроллере.
Но!
нашел какой то JS плагин, который подключаешь к таблице - и таблица на 1000 записей превращается в красивую табличку с пагинацией, с сортировкой по полям, с быстрым поиском по содержанию выведенных полей.
Но все равно больше 1000 записей на фронт в эту таблицу не подашь (да и много записей в JS - полюбому не годиться). Но с другой стороны, что лучше - убогая пагинация на 2-3к записей в контроллере, или чудная таблица на 1000 записей спагинированая на фронте? есть над чем подумать...
Можно погуглить по ключевым словам:
Давайте напишем свой фреймворк для паджинации в СФ без лимита в 2000?
да, просто отмигрировали легаси дату. Они точно знают сколько там записей...
Есть вариант сделать запрос к Storage Usage, распарсить HTML и получить реальное количество записей, даже если их > 1млн.
Ещё есть вариант завести свой счётчик и в триггере обновлять
Млин, народ. Какая пагинация больших списков?
Это баг архитектуры.
Повторю еще раз НАХРЕНА пользователю пагинация по 10000 записей? Да даже на 2000.
Дайте ему ПОИСК!
Серьезно вот тебе пример из жизни, зачем мне нужно больше 2000 записей. Мой пример больше правда относиться не к пагинации, а к dataTable
Так вот ты делаешь initial commit и тебе нужно видеть что ты вообше посылаешь в GIT. Так вот бывают проекты в которых более 2000 файлов и за один раз ты этого сделать не можешь, а очень хочется.
Обычно в таком случае используют навигацию в виде дерева (каталоги).
Чем тебе не замена пагинации?
Когда делаешь первый комит, нужно просматривать то что заливаешь, хотя бы на уровне типов метаданных.
И да дерево ничего не мешает сделать.
ооо, это точно. а то иногда приходишь на проект, а там в свне/гите такая жеппппа.
Но мы отвлеклись от основной темы.
С такими большими объёмами данных работать не так-то просто, знание того сколько записей, если их там 1M может пригодиться только для того чтобы показать - в этой таблице 1М записей. Потому что работать с такой большой таблицей без фильтрации SF вам не позволит 
- просто мило скажет что query должна быть selective ещё за долго до миллиона записей, т.е. как правильно заметили выше - фильтруйте. Причём в случае с такими объёмами данных не просто фильтруйте, а фильтруйте по полям которые индексируются (минимум это Name, External IDs, audit fields).
А в случае с 12K записей - почему бы не сделать это через связку JS + Ajax Toolkit + Apex - в JS формируете запрос, вытаскиваете только ID'шники (для быстроты), скармливаете эти ID'шники Apex'у, а он уже вытаскивает всё что надо. А для pagination используйте queryMore, который в JS доступен.
Да, не ожидал я, что все так сложно. казалось что все что нужно, сохранять во стейт вью номер страницы (точнее OFSET) и все...
что-то эта тема меня "не отпускает", какой-то "незавершенный гештальт".
посмотрел как одна контора сделала пагинирующийся список - там на OFFSETе, при этом не вижу никакого стопора на значение более 2000, видимо эта ситуация вообще не обрабатывается.
офсет хорош тем в СтайтВью не нужно грузить стандарный контроллер со всеми его записями. Но максимумальный размер списка меньше, чем можно выжать из пагинации на стандартном контроллере.
Я вот что подумал: есть хорошие JS плагины, который приведут твою <table> в прелестный вид, с пагинацией, быстрым поиском и прочее.
Но мы не может подать на фронт список размером более 1000 записей.
И теперь вопрос знатокам: а можем ли мы подать на фронт несколько Списков каждый размером в 1000 записей?
и если можем - то Репитором просто создаешь одну Таблицу из этих Списков, на которую и вешается Плагин.
А переменные со списками не даем сохраняться в СтайтВью.
и все счастливы (кроме браузера - ему конечно тяжеловато будет).
Но вообще в врп иногда приходилось делать лист внутри которого лист. И получался биглист
1000*1000 к примеру
сложные варианты со сложенными списками не рассматриваю.
А теперь представь что у тебя нет идишников, потому что ты работаешь не с записями из базы. Твое решение ?
Я для себя пока решил использовать json и сразу пулять его на страницу. А потом уже строить пагинацию на стороне клиента.
Я просто сторонник общих решиний. Для базы данных твой вариант почти идеален.
надо будет как-нибудь попробовать.
да, совсем забыл про json.
отстается только получить представление на каком объеме записей начнет загибаться браузер, т.к. какой-то лимит кол-ва записей по-любому должен быть. 10 тысяч бы подошло для большинства моих кейсов, так как реальное кол-во записей будет меньше, а если оно больше - то уже все, используйте фильтрацию.
Ага, еще дождись пока твои 10000 из базы загрузятся (не сломав heap size) и передадутся по "плохому" каналу на клиент.
Народ, да вы что? Где вы видели в реальном мире чтобы приложения по пол базы гоняли на каждый чих пользователя.
Да, 100, 200 записей ну 1000 еще куда ни шло. Но больше! Зачем? Понимаю что Salesforce со всем справится и не обидится. Но за такое на других платформах и база данных руки отрубают.
Еще можно смириться если у вас реально полноценное одностраничное приложение на JS написано, когда страница грузится 1 раз в сутки и потом просто работает. Тогда еще можно по частям, асинхронно грузануть N*1000 записей. Но все равно нет таких задач когда это жизненно необходимо и нельзя обойтись lazy loading.
Но учитывая что здесь все ярые поклонники Visualforce со стандартной процедурой загрузки страниц по http запросам, то явно ваши 10000 записей не к месту!
Если хотите супер крутую, быструю пагинацию. Просчитайте страницы заранее, сложите ID по страницам и сохраните отдельно в формате json (в базу). Потом подгрузите и пагинируйте сколько угодно. Да будут проблемы с удаление записей, надо будет перестраивать индекс страниц, но как говорится это меньшее зло.
Полностью согласен. Помню уже после того как написал это пришел к мысли что гибкостью тут и не пахнет.
жизнь заставила, так я живо нашел пример более-менее нормальной пагинации в контроллере, при которой записи (за исключением выводимых на фронт) не сохраняются в СтатьюВью (внутри Стандартного контроллера).
единственно, что в их примере, в "пагинирующем" цикле-селекте они кверят сразу записи со всеми полями.
а у меня записи "тяжелые", кверятся с дочерними записями, при лимите в 50000 можно и хип-сайз стукнуть.
так что в "пагинирующем" цикле-селекте можно выбирать\создавать список АйДи требуемых записей и после только их и кверить по-настоящему.
Если ты используешь OFFSET то у тебя скорее всего будет проблемы.
какой OFFSET? требуемый диапазон записей выбирается прямо в цикле-квери, у которого установлен лимит на 50к
//capture records within the target range
if(this.totalRecords>=this.startIdx && this.totalRecords<this.endIdx){
this.tRecords.add( new CCWRow(c, false) );
}
ну ладно, попробую подвести некоторой промежуточный итог по вариантам пагинации списков.
первая группа решений: пагинация на стороне контроллера:
1) пагинация посредством использования OFFSET в квери. выглядит не плохо, но, как известно, работает только до отметки в 2000.
2) пагинация посредством использования стандартного контроллера, описана как в блоге у Дмитрия, так у Джефа Дагласа (того самого, у которого вся жизнь как хакатрон).
неплохой вариант, но есть но - выкверинные записи сидят внутри стандартного контроллера, который будет переменной уровня контроллера, то есть идет прямехонько во СтайтВью. Если не принять меры, то странница упадет по СтайтВью примерно на 2-4 тыс записей.
а что можно сделать? я не пробовал, но как идея, изначально выбирать только АйДи, а затем заставить "стандартный контроллер" вернуть нужный диапазон АйДи и кверить уже только требуемые записи. Но не уверен, что это возможно сделать.
3) пагинация посредством выборки требуемого диапазона записей в цикле-квери (ссылка в предыдущих сообщениях). Полностью кастомное решение, выглядит оптимально. так как, вроде, все под твоим контролем. Имеет известное ограничение на 50к записей. Как оптимизацию предлагаю в "пагинирующем" цикле-квери выбирать только АйДи, а затем отдельно кверить уже полноразмерные записи только требуемого диапазона.
вторая группа решений: пагинация на стороне клиента:
4) "фейк" пагинация посредством JS плагина. Фактически на клиент подается полноразмерный список, со всеми вытекающими последствиями... Два под-варианта:
4-1) небольшого списка без попыток обойти лимиты на длину списка и СтайтВью. Может применяться только для предсказуемо и неизменно небольших списков, а такие бывают, например, список стран мира. Обычно в приложении всегда есть вспомогательные объекты-таблицы, содержащие относительно фиксированные данные.
4-2) "фейк" пагинация посредством JS плагина списка более 1к записей и размером превышающим СтайтВью: описано в одном из блогов в разделе Сссылки - все записи одномоментно подгружаются с помощью RemoteAction на онЛоад или онРеди событие. Неплохо, но зачем вам столько записей на клиенте?
5) Реальная пагинация на клиенте. Не пробовал, так как не вижу очевидных преимуществ перед пагинацией на контроллере для тех скучных "бухгалтерских" приложения с которыми работаю. Но вероятно, те кто работают с фронт-энд фреймворками скажут, что это уже все хорошо и просто организовано, только подключи к нужному RemoteAction, REST сервису или просто ВФ страницам, возвращающей JSON.
Добавляйте, комментируйте.
PS: еще забыл добавить выше:
4-3) если используется фейк-пагинация с помощью JS плагина, то для передачи на фронт списка более 1к не обязательно хитрить с RemoteAction, можно серилизовать список в JSON стринг.
Кстати да, отличное решение, сам использовал недавно.
Везде это использую. На страницу всегда передаю 1 серилизованный или не серилизованный DTO.
это идею wilder и подсказал, когда я еще бился с календарем, который по-существу явлется вариантом фронтовой пагинции.
мне вот только не понятно, что в таком случае делать со СтейтВью: вроде все переменные, доступные на фронте, прямиком идет в СтейтВью, если не объявляеть их как transient.
Я как раз по максимуму использую transient.
не использовать форму
так, так, что контроллерный state идет в СтейтВью только если на странице есть форма?
но если объявить страницу как ридОнли, это может и повлияет на лимит на СтейтВью, но не уверен
вообще да. Если есть apex:form есть view state. Нет формы - нет view state.
На странице ReadOnly вроде нельзя форму добавлять.
Если мне память не изменяет, форму там можно добавлять. В контроллере просто DML оперции запрещены как бы.
