Объясните пожалуйста как работает пэйджинг в Хайбернейте?

Вот пример
есть большой набор данных, причём получаться он в результате сложного SQL/HQL/JPQL запроса, для которого нужно сделать постраничный вывовод.

С Хайбернейтом работаю через JPA:

Query q = em.createQuery("select from...");
q.setFirstResult(900000);
q.setMaxResults(10);

0      row1 row2... rowN
...
900000 row1 row2... rowN \
900001 row1 row2... rowN |
...                      | данные нужные для страницы
900009 row1 row2... rowN |
900010 row1 row2... rowN /
...
100000 row1 row2... rowN

Предполагатся использование Сайбейса — там LIMIT X, Y как в Майэскуэле нет.
Как же это тогда работает?

Для субд эти инструкции будут одинаково тяжёлыми или нет?

Query q = em.createQuery("select from...");
q.setFirstResult(900000);
q.setMaxResults(10);

Query q = em.createQuery("select from...");
q.setFirstResult(1);
q.setMaxResults(10);

Здравствуйте, MV5, Вы писали:

MV5>Объясните пожалуйста как работает пэйджинг в Хайбернейте?
В диалекте прописан кусок SQL для реализации пейджинга.

MV5>Предполагатся использование Сайбейса — там LIMIT X, Y как в Майэскуэле нет.
MV5>Как же это тогда работает?
Судя по всему никак. Смотрю исходники диалекта — supportsLimit не переопределен, соответственно будет false как реализовано в базовом Dialect.

MV5>Для субд эти инструкции будут одинаково тяжёлыми или нет?
По идее да.

Здравствуйте, MV5, Вы писали:

MV5>

MV5>Query q = em.createQuery("select from...");
MV5>q.setFirstResult(1);
MV5>q.setMaxResults(10);
MV5>

На личном опыте убедился, что данную конструкцию использовать крайне не рекомендуется.
Лучше всего использовать scroll c выставлением setRowNumber.

Здравствуйте, timoshenkoap, Вы писали:

T>На личном опыте убедился, что данную конструкцию использовать крайне не рекомендуется.
T>Лучше всего использовать scroll c выставлением setRowNumber.

Как же так для чего же все эти вкусности?

Кстати я заметил такую тенденцию: довольно много людей просто "боится" этих как они говорят "черных ящиков". Мы лучше на JDBC все сами ручками сделаем.

Здравствуйте, MV5, Вы писали:

MV5>Кстати я заметил такую тенденцию: довольно много людей просто "боится" этих как они говорят "черных ящиков". Мы лучше на JDBC все сами ручками сделаем.
Ага, к примеру, сишники боятся виртуальной машины: не верят в быструю управляемую кучу и сборщик мусора — "мы лучше ручками напишем аллокацию/деаллокацию, так вернее"; программисты контроллеров (АСУ ТП) боятся использовать C/C++-код, опасаясь некорректности со стороны компиляторов от производителей контроллеров — "мы лучше на ассемблере накропаем"... и т.п. — все боятся рисковать и плодят ничем не примечательный серенький код.

Ну вообще то здесь дело не в Hibernate. Например доставание батча в MySQL сделано отлично, а вот MSSQL 2005 подкачал.
MSSQL чтобы достать 100 записей из 1000 сначала подымет эту тысячу, а потом достанет 100 что лично меня не устраивает.
По этому использовать куски пока указанные выше не рекомендуется. Никакие черные ящики здесь не причем.

Здравствуйте, timoshenkoap, Вы писали:

T>Ну вообще то здесь дело не в Hibernate. Например доставание батча в MySQL сделано отлично, а вот MSSQL 2005 подкачал. MSSQL чтобы достать 100 записей из 1000 сначала подымет эту тысячу, а потом достанет 100 что лично меня не устраивает.
Откуда такая информация? Рискну предположить, что Hibernate для MSSQL сделает классический запрос постраничной выборки: Постраничная выборка — см. вариант 1. Примерно такого вида:

declare
    @countOnPage int,
    @pageNumber int

set @countOnPage = 100
set @pageNumber = 2

select top(@countOnPage)
-- в Transact-SQL так нельзя, но это просто пример
    *
from SomeTable
where
    id not in (
        select top((@pageNumber - 1) * @countOnPage)
            id
        from SomeTable
        order by id
    )
order by id

И где здесь доставание 1000 записей???

T>По этому использовать куски пока указанные выше не рекомендуется. Никакие черные ящики здесь не причем.
В конце-концов можно посмотреть в логе Hibernate — какой будет сгенерирован запрос.

История такая происходила на реальном проекте. Помню долго не могли понять почему так долго работает на миллион объектов при батче в 50 тысяч ...
Исходники не смотрел, но проблема решилась именно через скрол.

Здравствуйте, timoshenkoap, Вы писали:

T>История такая происходила на реальном проекте. Помню долго не могли понять почему так долго работает на миллион объектов при батче в 50 тысяч ...
T>Исходники не смотрел, но проблема решилась именно через скрол.
А лучше не смотреть: мне скинули кусок кода те, кто смотрел — там действительно мрак.

Здравствуйте, MV5, Вы писали:

Посоветуйте, что почитать для правильной организации постраничного вывода, пожалуйста.
Как для Хайбернэйта так и вообще (для вообще кое что уже нашёл).
Кроме изучения исходников еще есть пути?

Как то мне это не очень понятно .

Спасибо.