Почему setFirstResult() в Query принимает параметр int?

Я реализую пользовательскую разбивку на страницы в Java, и мне интересно, почему Query принимает int в качестве аргумента? Это означает, что я не смогу разбить на страницы после того, как количество строк в БД превысит 2.147.483.647?

Есть ли способ использовать long вместо этого?


pagination jpa api-design
person Peter    schedule 17.08.2016    source источник
comment
серьезный? вы собираетесь разбить на страницы 2 миллиарда записей?   -  person Scary Wombat    schedule 17.08.2016
comment
только в теории, т.е. Я думаю, что в FB более 2 миллиардов постов.   -  person Peter    schedule 17.08.2016
comment
Если у вас такой огромный набор результатов, я думаю, вам нужно разбить на страницы условия запроса (что вам, вероятно, придется делать в любом случае из соображений производительности).   -  person Thilo    schedule 17.08.2016
comment
@Thilo, мои знания ограничены, но, насколько я понимаю, вы не можете явно использовать LIMIT(x,y) в JPQL (по крайней мере, я не мог), и Query решает это за вас (stackoverflow.com/questions/3479128/), поэтому в основном это запрос состояние.   -  person Peter    schedule 17.08.2016
comment
@Peter Нет реального случая использования, когда вы бы выполняли разбиение на страницы с таким огромным набором результатов. Если вы считаете, что вам это нужно, значит, вы где-то допустили серьезную конструктивную ошибку.   -  person Kayaman    schedule 17.08.2016
comment
а) вам не нужно использовать JPQL б) это можно сделать с помощью pagingTokens (ГДЕ sortField1 ›= ? AND sortField2›=? AND id › ? )   -  person Thilo    schedule 17.08.2016
comment
@Kayaman Вы совершенно правы, но могут быть очень особые случаи, когда это не вызвано недостатком дизайна, я думаю.   -  person Peter    schedule 17.08.2016
comment
@Thilo Спасибо, мне просто интересно, зачем мне добавлять ненужную логику и почему Query не поддерживает ее по умолчанию.   -  person Peter    schedule 17.08.2016

Ответы (1)


arrow_upward
1
arrow_downward

Потому что int достаточно велик с большим отрывом. Учитывая, что при использовании LIMIT/OFFSET рекомендуется иметь предложение ORDER BY для получения надежных результатов (иначе вы можете получить одинаковые строки на нескольких страницах), с набором результатов в 2 миллиарда строк вы будете сортировать результаты на сервере, а затем пропускать OFFSET строки. чтобы получить свою страницу, это будет довольно неэффективно даже до того, как вы доберетесь до пределов int.

person Kayaman    schedule 17.08.2016
comment
... что означает разбиение на страницы огромных наборов данных, вам все равно придется вставлять такие вещи, как WHERE sortField1 >= ? AND sortField2>=? AND id > ? в ваш запрос (т.е. страницу вручную, устраняя необходимость в OFFSET) - person Thilo; 17.08.2016
comment
@Тило Экзактомундо. - person Kayaman; 17.08.2016
comment
Я думаю, ваши рассуждения о ORDER BY достаточно верны. Спасибо вам обоим! - person Peter; 17.08.2016
comment
На самом деле больше похоже на WHERE sortField1 > ? OR (sortField1 = ? AND ( sortField2 > ? OR (sortField2 = ? AND id > ?)))... Некрасиво (если только вы не сортируете по одному и уникальному ключу). Но необходимо для производительности. - person Thilo; 17.08.2016
comment
@Peter Это основано на последней строке здесь. Хотя они говорят только, что это может быть неэффективно, но в любом случае это пустая трата места и энергии. - person Kayaman; 17.08.2016
comment
Кроме того, если вы просматриваете миллиард записей в глубину, есть вероятность, что есть одновременные обновления, которые также испортят разбиение на страницы. - person Thilo; 17.08.2016