Reject missing explicitly named queries

[014-code]

DATAJPA-1417 changes named query lookup so that repository methods explicitly declaring @Query(name = …) fail fast when the named query cannot be resolved.

Previously, if the configured named query was missing from both NamedQueries and the EntityManager, lookup could continue into query derivation. That fallback produced a misleading parameter-count error for methods whose name did not match the declared query parameters.

Changes

• Reject unresolved explicit @Query(name = …) declarations with a QueryCreationException.
• Keep existing fallback behavior for methods that do not explicitly declare a named query.
• Add a regression test covering the missing explicit named query path.

Tests

• .\mvnw.cmd -pl spring-data-jpa -Dtest=JpaQueryLookupStrategyUnitTests test
• .\mvnw.cmd -pl spring-data-jpa -Dtest=PreprocessedQueryUnitTests test

[mp911de]

I fail to understand how this pull request relates to #1731. Care to elaborate? The change on its seems reasonable.

[014-code]

I fail to understand how this pull request relates to #1731. Care to elaborate? The change on its seems reasonable.

Thanks for calling that out. The relation is in the lookup path shown by the stack trace rather than in native SQL parameter parsing itself.

In #1731, the repository method declares only @query(name = "StopDistanceQuery"). If that named query is not visible to the EntityManager, query lookup currently returns NO_QUERY and CREATE_IF_NOT_FOUND falls back to query derivation.

That fallback is visible in the reported stack trace:

CreateIfNotFoundQueryLookupStrategy -> PartTreeJpaQuery

The parameter-count error is therefore produced while deriving findNextStopByTripIdAndPosition, not while executing the named native query. The method has three bindable parameters, while the derived query path sees only two parts from the method name.

This PR changes that failure mode so an explicitly declared @query(name = …) fails fast when the named query cannot be resolved, instead of falling back to query derivation and surfacing the misleading parameter-count error.

It does not attempt to fix the provider-level native query parameter parsing mentioned in the later update. If you consider that to be the actual scope of #1731, I can remove the Closes #1731 reference and keep this as a related query lookup improvement.

[mp911de]

Thanks for sharing your thoughts.

I removed the relationship between the ticket and this pull request so we can treat it as a separate item. Since the change is a clear improvement, we can handle it within the scope of this PR.

With this change, a misspelled query name would silently fall back to query derivation. That is a relevant behavioral change for existing applications that currently boot successfully and would fail after this change.

[mp911de]

Thank you for your contribution. That's merged and polished now.