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

A signed numeric literal in JPQL, a space will be inserted between the sign and the numeric literal after parsing #3342

Closed
hgwr opened this issue Jan 31, 2024 · 2 comments
Assignees
Labels
type: bug A general bug

Comments

@hgwr
Copy link
Contributor

hgwr commented Jan 31, 2024

If you use a signed numeric literal in JPQL, a space will be inserted between the sign and the numeric literal after parsing, resulting in a syntax error.

Reproduction environment

$ java -version
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
java version "17.0.6" 2023-01-17 LTS
Java(TM) SE Runtime Environment (build 17.0.6+9-LTS-190)
Java HotSpot(TM) 64-Bit Server VM (build 17.0.6+9-LTS-190, mixed mode, sharing)
dependencies {
   implementation 'org.springframework.data:spring-data-jpa:3.2.3-SNAPSHOT'
}

How to reproduce

You can reproduce it by running the Spring Boot web application from the https://github.com/hgwr/try-negative-one repository.

The JPQL query SELECT m FROM Memo m WHERE m.categoryId = -1 is used in the application. If you call it like curl "http://127.0.0.1:8080/memo/category/negative-one", you will get the following exception.

ERROR 86400 --- [nio-8080-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: org.springframework.dao.InvalidDataAccessApiUsageException: An exception occurred while creating a query in EntityManager: 
Exception Description: Syntax error parsing [SELECT m FROM Memo m WHERE m.categoryId = - 1]. 
[27, 45] The expression is not a valid conditional expression.] with root cause

org.eclipse.persistence.exceptions.JPQLException: 
Exception Description: Syntax error parsing [SELECT m FROM Memo m WHERE m.categoryId = - 1]. 
[27, 45] The expression is not a valid conditional expression.
        at org.eclipse.persistence.internal.jpa.jpql.HermesParser.buildException(HermesParser.java:159) ~[org.eclipse.persistence.core-4.0.2.jar!/:na]

As shown in the exception error message, WHERE m.categoryId = -1 is parsed to include a space between the sign and the numeric literal, such as WHERE m.categoryId = - 1 .

Suggestions for solutions

Pull Request #3343

In the process of adding the sign token below, we suggest suppressing the addition of spaces by setting false to the second argument of the constructor JpaQueryParsingToken.

@christophstrobl
Copy link
Member

@hgwr thanks for raising the issue and taking the time to craft the PR!

@christophstrobl christophstrobl self-assigned this Feb 1, 2024
@christophstrobl christophstrobl added type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged labels Feb 1, 2024
@christophstrobl
Copy link
Member

The problem is also present for signed expressions like -count(u). We'll fix that as well.

christophstrobl pushed a commit that referenced this issue Feb 1, 2024
This commit fixes an issue where an extra space is added between the sign and the actual value of signed numerics.

Closes: #3342
Original Pull Request: #3343
christophstrobl added a commit that referenced this issue Feb 1, 2024
This commit makes sure to retain signed expressions (hql, jpql) and literals (jpql) when rendering the query.
Prior to the change singed expression/literal rendering added a space between the sign and the actual value so that `-1` would become `- 1` and `-count(u)` would be `- count(u)`.
Additionally a minor glitch in the jpql rendering was resolved that would add an extra space before the closing bracket of a LENGTH expression.

See: #3342
christophstrobl added a commit that referenced this issue Feb 1, 2024
This commit makes sure to retain signed expressions (hql, eql, jpql) and literals (eql, jpql) when rendering the query.
Prior to the change singed expression/literal rendering added a space between the sign and the actual value so that `-1` would become `- 1` and `-count(u)` would be `- count(u)`.
Additionally a minor glitch in the jpql rendering was resolved that would add an extra space before the closing bracket of a LENGTH expression.

See: #3342
christophstrobl pushed a commit that referenced this issue Feb 1, 2024
This commit fixes an issue where an extra space is added between the sign and the actual value of signed numerics.

Closes: #3342
Original Pull Request: #3343
christophstrobl added a commit that referenced this issue Feb 1, 2024
This commit makes sure to retain signed expressions (hql, eql, jpql) and literals (eql, jpql) when rendering the query.
Prior to the change singed expression/literal rendering added a space between the sign and the actual value so that `-1` would become `- 1` and `-count(u)` would be `- count(u)`.
Additionally a minor glitch in the jpql rendering was resolved that would add an extra space before the closing bracket of a LENGTH expression.

See: #3342
@christophstrobl christophstrobl added this to the 3.1.9 (2023.0.9) milestone Feb 1, 2024
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