Skip to content

DATAJPA-1750 - Fixes order clause creation if function with parameter… #425

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

Conversation

simonparadies
Copy link

@simonparadies simonparadies commented Jun 28, 2020

  • You have read the Spring Data contribution guidelines.
  • There is a ticket in the bug tracker for the project in our JIRA.
  • You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
  • You submit test cases (unit or integration tests) that back your changes.
  • You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

@schauder
Copy link
Contributor

Thanks for looking into this. The problem, not with your PR, but with the current situation is, that the current approach of parsing the queries is not maintainable and need some serious work.
This rework should solve the underlying problem.

I'd like to keep the PR open though, in order to eventually merge at least the tests, in order to verify everything works as intended.

@schauder schauder changed the title DATAJPA-1750 - Fixes order clause creation if function with parameter… DATAJPA-1750 - #depends on parser# Fixes order clause creation if function with parameter… Oct 21, 2020
@schauder schauder changed the title DATAJPA-1750 - #depends on parser# Fixes order clause creation if function with parameter… DATAJPA-1750 - Fixes order clause creation if function with parameter… Oct 21, 2020
@simonparadies
Copy link
Author

simonparadies commented Oct 23, 2020

I'd like to keep the PR open though, in order to eventually merge at least the tests, in order to verify everything works as intended.
Since this PR solves the issue at hand, why not merge it as-is now?
The problem, not with your PR, but with the current situation is, that the current approach of parsing the queries is not maintainable and need some serious work. This rework should solve the underlying problem.
Imo that is a different and independent problem which should not delay this fix. I'd like to get away from ugly and imperformant work-arounds asap. I am afraid that a major rework will take its time. Merging the PR now does not impede a rework in any way. Thanks!

@gregturn gregturn changed the base branch from master to main April 15, 2021 18:45
gregturn added a commit that referenced this pull request May 19, 2022
@gregturn gregturn closed this in f5ddb7a May 19, 2022
@gregturn gregturn self-assigned this May 19, 2022
@gregturn gregturn added type: enhancement A general enhancement in: query-parser Everything related to parsing JPQL or SQL and removed revisit-after-parser-rewrite labels May 19, 2022
@gregturn gregturn added this to the 3.0 M5 (2022.0.0) milestone May 19, 2022
@gregturn gregturn added type: bug A general bug and removed type: enhancement A general enhancement labels May 19, 2022
gregturn added a commit that referenced this pull request May 19, 2022
gregturn added a commit that referenced this pull request May 19, 2022
@gregturn
Copy link
Contributor

Backported to 2.7.x and 2.6.x.

Thanks @simonparadies!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: query-parser Everything related to parsing JPQL or SQL type: bug A general bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants