Наркоман.

https://vladmihalcea.com/the-best-way-to-map-a-onetomany-association-with-jpa-and-hibernate/ Therefore, in reality, @OneToMany is practical only when many means few. Maybe @OneToFew would have been a more suggestive name for this annotation.

И вам тоже советую почитать спецификацию :) getResultStream() завезли в JPA 2.2, а предлагаемый вариант с постраничной разбивкой он, откровенно говоря, так себе - работает только в режиме SERIALIZABLE. Да и ТС не нужно это - он хочет делать так:

Ну в спецификацию же вы первый начали морду лица тыкать, ну вот обратка пришла да, getResultList() плохой. Нет, полноценный getResultStream() в хибере начиная с 5.3, а не с 6.0 - читайте release notes.

Нет, я просто хрень вижу издалека: вы своим советом с пагинацией единственное что можете, так это задрочить базу до смерти, потому что в предлагаемом решении никакого ключа для сортировки нет, поэтому на каждый вызов будет возвращаться какой-то мусор, да еще и база будет потеть, потому что чтобы что-то пропустить, нужно сначала это что-то прочитать.

Пагинация - отстой, подходит только для web.

Странно... читать не хотите вы, а виноват в этом я...

https://github.com/eclipse-ee4j/jpa-api/issues/99 Reading large datasets using JPA is quite uncomfortable these days as all method signatures return {{List}}s, which causes the entire result set to be pulled into memory before it can be handed to clients. Currently users work around this by paging through the results which sort of works but is error prone regarding inserts and deletes that might touch the same set of data to be read causing inconsistencies while iterating.

It would be great if alternatives to access a Stream (on JDK 8) or an AutoCloseableIterable (on JDK 7) could be provided to lazily iterate over a result set, e.g. EntityManager.stream(…) analog to the find(…) methods as well as Query.getResultStream().

It might be worth thinking about being able to hand an eviction policy to those methods to define rules to evict managed types from the EntityManager as otherwise the persistence context will inevitably grow during the streaming operation.


Вы понимаете что означает фраза "causing inconsistencies while iterating"?

Просто замечательно, у меня фантазии, у самого главного в JPA фантазии, но каким образом справочник в liquibase относится к топику?


Увы, видимо не в коня корм, придется объяснять для особо одаренных.

Вот нам нужно каким-то образом обработать кучу записей, JPA для подобных вещей совершенно не предназначен - у него цели несколько иные, вы же предлагаете остаться в рамках JPA, но еще и делать это через откровенную жопу, а именно:

вот у нас есть какой-то запрос вида (для наглядности синтаксис из MySQL):




Вопрос: какой контракт должна соблюсти СУБД для обращения типа: "ты там что-то повыбирай, а потом отдай некий кусок того что получилось"? контракт здесь только один: если количество строк между M и M+N, то количество возвращаемых строк должно не превышать N, т.е. когда вы пытаетесь с каждым запросом увеличивать OFFSET, БД не предоставляет никаких гарантий, что:
- вы не получите ранее прочитанные данные
- вы не пропустите данные

чтобы хоть какие-то "гарантии" появились нужно на таблице tbl вводить отношение порядка и указывать его в ORDER BY, тогда мы будем говорить базе следующее: ты там что-то выбери, потом отсортируй, а потом выкинь M строк и отдай N. Вопрос: вот зачем нам базе говорить "выбери все и выкинь M строк" (т.е. с каждым разом все будет происходить медленнее и медленнее) если у нас уже есть отношение порядка на таблице и мы можем сразу сказать "давай выбирай с этого места", нужно только запомнить предыдущее место?

ну вот мы вроде бы все соблюли, но есть одно "но": пока мы что-то там делаем в то же время из БД могут как удалять записи, так и вставлять новые, при этом если отношение порядка и существует, то нет никаких гарантий что в БД не напихают данных, который по этому отношению порядка окажутся "более старыми" нежели мы сейчас вычитываем? И вот вопрос: зачем все это делать, если есть куда более бронебойные способы, а именно:
- можно выбрать только идентификаторы - вполне возможно что они в память поместятся
- использовать getResultStream, вместо getResultList
- выставить JPA на улицу и использовать всю мощь JDBC
- сделать собственную очередь в которую никто залезть не будет (здесь из накладных расходов только insert select)

пагинация - это самый ущербный (и неработающий) способ.