Здесь много бесчисленных вопросов, как решить проблему "не удалось инициализировать прокси", пытаясь получить, открыв транзакцию, открыв другую, OpenEntityManagerInViewFilter
и т.д.
Но можно ли просто сказать Hibernate игнорировать проблему и притворяться, что коллекция пуста? В моем случае, не доставляя его раньше, просто означает, что мне все равно.
На самом деле это проблема XY со следующим Y:
У меня есть классы вроде
class Detail {
@ManyToOne(optional=false) Master master;
...
}
class Master {
@OneToMany(mappedBy="master") List<Detail> details;
...
}
и хотите обслуживать два типа запросов: один возвращает один master
со всеми его details
, а другой возвращает список master
без details
. Результат преобразуется в JSON Gson.
Я пробовал session.clear
и session.evict(master)
, но они не касаются прокси-сервера вместо details
. Что работало
master.setDetails(nullOrSomeCollection)
который чувствует себя довольно взломанным. Я бы предпочел "незнание", поскольку это применимо вообще, не зная, какие части проксированных.
Запись Gson TypeAdapter
игнорирование экземпляров AbstractPersistentCollection
с помощью initialized=false
может быть способом, но это будет зависеть от org.hibernate.collection.internal
, что, безусловно, не очень хорошо. Улавливание исключения в TypeAdapter
звучит не намного лучше.
Обновление после некоторых ответов
Моя цель состоит не в том, чтобы "получить загруженные данные вместо исключения", но "как получить null вместо исключения" I
Драган поднимает действительный момент, когда забывание забрать и вернуть неверные данные будет намного хуже, чем исключение. Но там есть простой способ:
- делать это только для коллекций
- никогда не используйте
null
для них - return
null
, а не пустая коллекция в качестве индикатора необработанных данных
Таким образом, результат никогда не может быть неправильно интерпретирован. Должен ли я когда-либо забыть что-то получить, ответ будет содержать null
, который недействителен.