fix(jpa): unwrap literal value in NULLIF function mapping - #202
Merged
Merged
Conversation
JpaFunctionMapper.nullif passed the Querity Literal wrapper straight to CriteriaBuilder.nullif(Expression, Y), which treats Y as the raw literal value. Hibernate then failed to convert the wrapper to the expression type: Could not convert 'io.github.queritylib.querity.api.Literal' to 'java.lang.String' using 'org.hibernate.type.descriptor.java.StringJavaType' Unwrap the literal with getValue(), mirroring what toExpressionOrLiteral already does for every other function. Any other argument type now goes through toExpressionOrLiteral (CASE WHEN workaround for property expressions), so unsupported types fail fast instead of reaching CriteriaBuilder. Fixes #201 Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #201
Problem
A projection using
NULLIFwith a literal second argument — e.g.NULLIF(lastName, "Skywalker")— parsed fine but blew up at execution:Reproduced on both H2 and PostgreSQL.
Root cause
JpaFunctionMapper.nullifpassed the QuerityLiteralwrapper toCriteriaBuilder.nullif(Expression<Y>, Y), which treatsYas the raw literal value. Every other function site unwraps viatoExpressionOrLiteral/cb.literal(lit.getValue()); thenullifliteral branch skipped it.This is distinct from the condition-side conversion fixed in
fcab732(JpaOperatorMapper), which does not cover the function-mapper site.Fix
Unwrap the literal with
getValue()before passing it tocb.nullif. The branches are also inverted so that anything that is not aLiteralgoes throughtoExpressionOrLiteral(which keeps theCASE WHENworkaround for property expressions and fails fast on unsupported argument types, instead of silently reachingCriteriaBuilder).Tests
givenSelectWithNullifFunctionAndLiteral_whenFindAllProjected_thenReturnProjectedResults, asserting the actual projected values (nullfor rows matching the literal). It runs onquerity-jpa,querity-spring-data-jpa(H2 + PostgreSQL) andquerity-spring-data-mongodb; Elasticsearch is excluded by the existingsupportsFunctionExpressionsInProjections()gate. It fails onmainwith the exception above.verify(cb).nullif(any(), eq("INACTIVE"))— it previously passed even with the bug, because the mock accepted anyObject../mvnw clean verifyis green across all 12 modules.🤖 Generated with Claude Code