Может кто-нибудь сказать мне внутренние причины, почему в JPA 1.0 EntityManager при извлечении объекта через find вы должны иметь дело с null, если не нашли, но при использовании интерфейса Query через createQuery getResultList бросает NoResultException, если не найден.
Возможно, я что-то упускаю, но я чувствую, что он очень несовместим с языком, и на самом деле мне пришлось много переделать из-за перехода с простого искателя на более мелкозернистый запрос с использованием интерфейса запроса.
Спасибо, ребята.
Запросы могут использоваться для извлечения почти всех, включая значение одного столбца в одной строке.
Если getSingleResult() вернет значение null, вы не можете определить, не соответствует ли запрос какой-либо строке или соответствует ли запрос строке, но выбранный столбец содержит значение null.
Когда вы выполняете поиск, jpa будет использовать первичный ключ для поиска объекта сущности, часто используя кеш второго уровня, и он обычно намного быстрее, чем createQuery и getSingleResult.
Вы либо получаете null, либо объект обратно из find. Когда вы создаете createQuery и создается экземпляр объекта Query. Если вы используете getResultList, он не будет генерировать исключение NoResultException, только если вы получите getSingleResult, оно выкинет это исключение. Если вы выполняете getResultList, и ни один не найден, возвращается null.
Кроме того, NoResultException будет отмечать откат транзакции в weblogic 10.3.2.
Смотрите эту статью: NoResultException отмечает откат транзакций
Я думаю, что он устраняет эту нулевую проверку:
Object o = q.getSingleResult();
if (o != null)
return (MyObj) o;
return o;
Внедряя RuntimeException (NoResultException), программисты могут безопасно использовать q.getSingleResult() в MyObj и оставить исключение для вызывающего.
Что касается q.getResultList(), он всегда будет возвращать список, нуль-проверка не требуется.
Но я все еще чувствую это неинтуитивным.