Лучшие способы использования ленивой нагрузки

Question

У меня очень длинная цепочка объектов, все из которых будут загружаться лениво. Мы используем JPA (не повезло на fetchmodes)

В некоторых случаях нам не нужно загружать полный объектный граф, в этих случаях производительность хорошая. Но в немногих других случаях нам, возможно, придется загрузить полный объект Graph, как показано ниже.

Ниже классов для представительских целей только

FirstObject.java 

@Lazy 
private Set<SecondObject> 

---

SecondObject.java  
@Lazy 
private Set<ThirdObject> // may load 20-30 objects 
@Lazy 
private Set<FourthObject> // may load 20-30 objects 

---

ThirdObject.java 
@Lazy 
private Set<FourthObject> // may load 10 - 100 records 

---

FourthObject.java 
@Lazy 
private Set<FifthObject> // may load 10-100 records 

.
.
.
(список можно продолжить)

Пограничный случай

Если вы видите, каждый ребенок загружает несколько детей, и нет никакого способа избежать. Представьте, что пользователь пытается загрузить Firstobject.java, и ему нужен полный граф объектов до графика FifthObject.java.

firstObject = session.get(FirstObject.class, 10); 

// Поскольку все дети ленивы, он пытается инициализировать их, как показано ниже.

firstObject.getSecondObject().size() // size() for load all the lazy children 

// Теперь каждый из ребенка является сбор и они ленивы, так что он должен сделать следующее

for(SecondObject sec: firstObject.getSecondObject()){ 
    sec.getThirdObject().size(); 
    //because third object needs fourth object we loop third and get all ffourth 
} 

Все выше код занимает около 7-10 секунд для запуска, и может быть больше, если дети больше.

Вопрос: Как загрузить объекты в этом случае? взаимодействие пользователя настолько неустойчиво, что нам может понадобиться или не понадобиться полный график.

Я думал об использовании настраиваемого языка JPQL/native SQL, который объединяет все связанные дочерние элементы и возвращает объекты Entity в качестве одного из параметров, но задается вопросом, хороши ли все усилия.

Примечание: пользователю может не понадобиться вся информация, возвращаемая в графе объектов, но ему требуется только несколько свойств для показа (но для этого нужны все объекты).

Answer 1

Я думал об использовании пользовательского языка JPQL/native SQL, который объединяет все связанные дочерние элементы и возвращает объекты Entity как один из параметров, но задается вопросом, хороши ли все усилия.

Я думаю, что это хороший вариант для вас. Вы должны как-то суммировать эту информацию в базе данных и свести к минимуму создание объектов в вашем приложении. Приведение всех этих объектов в основную память просто для выполнения некоторых вычислений - плохая идея.

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