Будьте в спящем режиме (JPA), как сделать нетерпеливый запрос, загрузив все дочерние объекты

Другое событие NullPointerException возникает, когда объявляется массив объектов, а затем сразу же пытается разыменовать его внутри.

String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
    System.out.println(phrase.equals(keyPhrase));
}

Этот конкретный NPE можно избежать, если порядок сравнения отменяется ; а именно, использовать .equals для гарантированного непустого объекта.

Все элементы внутри массива инициализируются их общим начальным значением ; для любого типа массива объектов, это означает, что все элементы null.

Вы должны инициализировать элементы в массиве перед доступом или разыменованием их.

String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
    System.out.println(phrase.equals(keyPhrase));
}

20
задан Community 23 May 2017 в 10:31
поделиться

7 ответов

Изменение аннотации является плохой идеей IMO. Поскольку это не может быть изменено на ленивый во времени выполнения. Лучше сделать все ленивым, и выборка по мере необходимости.

я не уверен, что понимаю Вашу проблему без отображений. Оставленная выборка соединения должна быть всем, в чем Вы нуждаетесь для варианта использования, который Вы описываете. Конечно, Вы возвратите порядок на каждый orderline, если orderline будет иметь порядок как своего родителя.

14
ответ дан 30 November 2019 в 01:03
поделиться

Я не уверен в использовании ключевого слова выборки в Вашем EJBQL, Вы могли бы получать перепутанный с аннотацией...

Вы попытались добавить свойство FetchType к своему атрибуту отношений?

@OneToMany (fetch=FetchType. НЕТЕРПЕЛИВЫЙ)?

См.:

http://java.sun.com/javaee/5/docs/api/javax/persistence/FetchType.html http://www.jroller.com/eyallupu/entry/hibernate_exception_simultaneously_fetch_multiple

8
ответ дан 30 November 2019 в 01:03
поделиться

Вы смогли делать что-то как это использование (отдельного) запроса критериев и установка режима выборки. Например,

Session s = ((HibernateEntityManager) em).getSession().getSessionFactory().openSession();
DetachedCriteria dc = DetachedCriteria.forClass(MyEntity.class).add(Expression.idEq(id));
dc.setFetchMode("innerTable", FetchMode.JOIN);
Criteria c = dc.getExecutableCriteria(s);
MyEntity a = (MyEntity)c.uniqueResult();
2
ответ дан 30 November 2019 в 01:03
поделиться

Вы попытались использовать преобразователь результата? При использовании запросов Критериев можно применить преобразователь результата (хотя существуют некоторые проблемы с разбиением на страницы и преобразователем результата ):

Criteria c = ((Session)em.getDelegate()).createCriteria(Order.class);
c.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY);
c.list();

эти em.getDelegate() взлом, который только работает, если Вы используете, в спящем режиме.

, Возможно, что еще более важно, там способ вытянуть во всех дочерних объектах, неважно, как глубоко? У нас есть приблизительно 10-15 классов, и для сервера нам будет нужно все загруженное... Я избегал использования FetchType. НЕТЕРПЕЛИВЫЙ, поскольку это означало его всегда нетерпеливый, и в особенности веб-фронтэнд загружает все - но возможно который является способом пойти - это, что Вы делаете? Я, кажется, помню нас пробующий это прежде и затем получающий действительно медленные веб-страницы - но возможно который означает, что мы должны использовать кэш второго уровня?

, Если Вам все еще интересно, я ответил подобный вопрос в этом потоке , как сериализировать, в спящем режиме наборы .

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

3
ответ дан 30 November 2019 в 01:03
поделиться

Это только работало бы на отношения ManyToOne и на них @ManyToOne (fetch=FetchType. НЕТЕРПЕЛИВЫЙ), вероятно, адаптировал бы.

Выборке больше чем одного отношения OneToMany нетерпеливо препятствуют и/или не работает, поскольку можно читать в ссылке, которую отправил Jeremy. Просто думайте о SQL-операторе, который был бы необходим, чтобы сделать такую выборку...

0
ответ дан 30 November 2019 в 01:03
поделиться

То, что я сделал, должно осуществить рефакторинг код для хранения карты объектов менеджерам по объекту и каждый раз, когда я должен обновить, закрыть старый entitymanager для объекта и открыть новый. Я использовал вышеупомянутый запрос без выборка , поскольку это идет слишком глубоко для моих потребностей - просто выполнение плоскости присоединяется к получениям по запросу в OrderLines - , выборка заставляет его пойти еще глубже.

существует только несколько объектов, что мне нужно это для, приблизительно 20, таким образом, я думаю, что ресурс наверху в наличии 20 открытых entitymanagers не является проблемой - хотя DBAs может иметь другое представление, когда это идет живое...

я также переделал вещи так, чтобы работа дб была на основном потоке и имела менеджера по объекту.

Chris

0
ответ дан 30 November 2019 в 01:03
поделиться

Если проблемой является просто LazyInitializationExceptions, можно избежать этого путем добавления OpenSessionInViewFilter.
Это позволит объектам быть загруженными в представлении, но не поможет с проблемой скорости.

     <filter>
        <filter-name>hibernateFilter</filter-name>
        <filter-class> org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
        </filter-class>
    </filter>
    <filter-mapping>
        <filter-name>hibernateFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
-4
ответ дан 30 November 2019 в 01:03
поделиться
Другие вопросы по тегам:

Похожие вопросы: