Switch to JPA 3.2 Query.getSingleResultOrNull()

[david-kubecka]

I'm talking about this code: https://github.com/spring-projects/spring-data-jpa/blob/main/spring-data-jpa/src/main/java/org/springframework/data/jpa/repository/query/JpaQueryExecution.java#L224. As we know, getSingleResult throws an exception upon a non-existing entity. Since this is an allowed situation the exception is caught here https://github.com/spring-projects/spring-data-jpa/blob/main/spring-data-jpa/src/main/java/org/springframework/data/jpa/repository/query/JpaQueryExecution.java#L92.

I wonder why this try/catch approach (generally frowned upon) is used here instead of an alternative approach using getResultList, see e.g. https://stackoverflow.com/a/2885024/13015027. Apart from a slight performance penalty (not measured), the biggest problem of the current approach is that the exception is captured by telemetry agents (see open-telemetry/opentelemetry-java-instrumentation#12125).

[mp911de]

the biggest problem of the current approach is that it pollutes the logs.

Care to elaborate? There should be no logging involved from our side. We could actually switch to uniqueResultOptional. Just noticed that uniqueResultOptional is Hibernate-specific and not something that JPA defines.

Looking at the getSingleResult implementations, implementations use it merely as wrapper for getResultList post-processing.

[david-kubecka]

I've clarified the issue with a link (which I've found meanwhile) to an opentelemtry issue.

[mp911de]

This ticket is a duplicate of #3633

[david-kubecka]

Ok, the linked ticket has a much better description of the underlying OTEL problem.

Still, I would like to understand why it wouldn't be possible to replace the current getSingleResult call with an approach similar to the linked SO answer. AFAIK that one doesn't rely on anything Hbernate specific, utilizing plain JPA only.

[mp911de]

We comply with the JPA spec by using getSingleResult(). If we now change (after using that functionality for almost 15 years) to a different strategy, I am pretty sure that we will break someone else's application because, in some particular cases, Hibernate (or Eclipselink) is doing things in getSingleResult() slightly differently than in getResultList().

[david-kubecka]

We comply with the JPA spec by using getSingleResult().

Can you please point me to a guideline that mandates that you must use getSingleResult in this situation?

[mp911de]

From the Javadoc:

Execute a SELECT query that returns a single untyped result

and for getResultList:

Execute a SELECT query and return the query results as an untyped List

Going forward, the spec mentions:

NoResultException

The NoResultException is thrown by the persistence provider when Query.getSingleResult is invoked and there is no result to return. This exception will not cause the current transaction, if one is active, to be marked for rollback.

NonUniqueResultException

The NonUniqueResultException is thrown by the persistence provider when Query.getSingleResult or Query.getSingleResultOrNull is invoked and there is more than one result from the query. This exception will not cause the current transaction, if one is active, to be marked for rollback.

With JPA 3.2, we can switch to getSingleResultOrNull().

[david-kubecka]

Yes, I read that doc snippets. And I see nothing in them that would indicate that using getResultList in your case is wrong or unsafe (assuming, of course, that providers implement the specification correctly).

Anyway, looks like getSingleResultOrNull could be available soon so if you are willing to use that then perhaps you can do that under this ticket (I can add getSingleResultOrNull as another option to the description).

[mp911de]

Alright, I repurposed this ticket and marked it for inclusion for our 4.0.x branch.