Skip to content

Exception swallowed in CreateIfNotFoundQueryLookupStrategy.resolveQuery [DATAJPA-1723] #2018

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
spring-projects-issues opened this issue May 8, 2020 · 2 comments
Assignees
Labels
type: bug A general bug

Comments

@spring-projects-issues
Copy link

ckalan opened DATAJPA-1723 and commented

Exception thrown from lookupStrategy.resolveQuery() is swallowed without proper logging before falling back to createStrategy. 

In my case it occured when I used @Query annotation in my repo method with "name" attribute pointing to a JPA Named Query declared on the entity. The problem was I also used Sort parameter and I got "propert not found for type ..." exception. In fact the inner exception was thrown by "NamedQueries" class with this code:

throw new IllegalStateException(String.format("Finder method %s is backed " + "by a NamedQuery and must "
  + "not contain a sort parameter as we cannot modify the query! Use @Query instead!", method));

It took me a couple of hours to identify the issue and I had to deep dive in the code because there was no debug log for the actual error. In addition to the logs, it might be a good idea to update the docs to mention this limitation. 

Note that this happens in 2.2.6 RELEASE version that comes with Spring Boot but that version is not listed in the Affects Version/s field above.  

 


No further details from DATAJPA-1723

@gregturn
Copy link
Contributor

gregturn commented May 18, 2022

Part of the problem is that JpaQueryLookupStrategy is using exceptions for flow control inside resolveQuery

@Override
protected RepositoryQuery resolveQuery(JpaQueryMethod method, QueryRewriter queryRewriter, EntityManager em,
		NamedQueries namedQueries) {

	try {
		return lookupStrategy.resolveQuery(method, queryRewriter, em, namedQueries);
	} catch (IllegalStateException e) {
		return createStrategy.resolveQuery(method, queryRewriter, em, namedQueries);
	}
}

This method will catch an IllegalStateException and pivot to creating a query instead of simply looking it up. But in some circumstances this is the wrong action to take.

gregturn added a commit that referenced this issue May 18, 2022
By using exceptions for flow control, other critical exceptions are getting masked. The lack of a resolvable query should instead leverage some sort of null value object.

Closes #2018.
gregturn added a commit that referenced this issue May 18, 2022
By using exceptions for flow control, other critical exceptions are getting masked. The lack of a resolvable query should instead leverage some sort of null value object.

Closes #2018.
@gregturn gregturn added type: bug A general bug and removed type: enhancement A general enhancement labels May 18, 2022
@gregturn gregturn added this to the 3.0 M5 (2022.0.0) milestone May 18, 2022
gregturn added a commit that referenced this issue May 18, 2022
By using exceptions for flow control, other critical exceptions are getting masked. The lack of a resolvable query should instead leverage some sort of null value object.

See #2018.
gregturn added a commit that referenced this issue May 18, 2022
By using exceptions for flow control, other critical exceptions are getting masked. The lack of a resolvable query should instead leverage some sort of null value object.

See #2018.
gregturn added a commit that referenced this issue May 18, 2022
By using exceptions for flow control, other critical exceptions are getting masked. The lack of a resolvable query should instead leverage some sort of null value object.

See #2018.
@gregturn
Copy link
Contributor

Backported to 2.7.x, 2.6.x, and 2.5.x.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A general bug
Projects
None yet
Development

No branches or pull requests

3 participants