Skip to content
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

Mixing SpEL and String @Param is not possible if not all parameters are used as SpEL expression in @Query on Repository [DATAJPA-1140] #1483

spring-projects-issues opened this issue Jun 26, 2017 · 1 comment
in: core type: bug


Copy link

@spring-projects-issues spring-projects-issues commented Jun 26, 2017

Kevin Peters opened DATAJPA-1140 and commented

Due to a binding issue it's not possible to mix a SpEL @Param and a String @Param on a Repository finder annotated with @Query if not all incoming parameters are used in SpEL syntax.

Example which fails:

@Query("FROM DataEntity de WHERE = :#{#spELValueObject.fooValue} AND = :barValue")
DataEntity findByMixedParamsStringLast(@Param("spELValueObject") SpELValueObject spELValueObject,
			@Param("barValue") String barValue);

This exception is thrown.

Using String parameter as SpEL works:

@Query("FROM DataEntity de WHERE = :#{#spELValueObject.fooValue} AND = :#{#barValue}")
DataEntity findByMixedParamsStringLastPlusFakeSpEL(@Param("spELValueObject") SpELValueObject spELValueObject,
			@Param("barValue") String barValue);

The order of the params (SpEL first / SpEL last) does not matter

Affects: 2.0 M4 (Kay)

Issue Links:

  • DATAJPA-1103 @Query method with mixed SpEL and simple binding failed
    ("is duplicated by")
  • DATAJPA-963 LIKE operator % in countQuery not working as expected
    ("is duplicated by")

Referenced from: pull request #206, and commits d15139f, c76584f, f2ede44, 8dbbe55, f97928e, b9a57f8, 7a21c8f, 6bedbab, 0529f69, d7c3d01, 3568c51, 3fd8ef2, 3925be3, 3620ab2, 37aabff

Copy link

@spring-projects-issues spring-projects-issues commented Jul 7, 2017

Jens Schauder commented

Quick explanation for the QueryParameterSetter abstraction in the current PR and general overview (might eventually become the discussed wiki article).

For the binding a couple of choices have to be made:

  1. The general approach how to match parameters in the query and parameters in the method call.

    • either we iterate the method parameters (and basically hope the matching (by name or index) parameters exist in the query). This is implemented in the ParameterBinder.bind(Query
    • if we have the StringQuery we can ask it for the parameters and find matching method parameters (or other sources i.e. SpEL expressions).
  2. Decide which query parameter should be filled from which source

    • use whatever method parameter is available and assume a matching query parameter exists
    • find parameter by index or name
    • use a SpEL expression
      This choice is implemented in the ParameterBinder.bind(JpaParameter parameter, Object value, Integer position) and in QueryParameterSetterStrategies;
  3. Decide how to set the parameter value in the query. This is encoded in the various QueryParameterSetters

    • use index or name or ParameterExpression based access
    • provide a TemporalType or not
    • Ignore certain exceptions or not
    • Just don't

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: core type: bug
None yet

No branches or pull requests

2 participants