Summary
QueryUtils.FUNCTION_PATTERN (QueryUtils.java:187) uses the character
class [\w\.,\s'=:;\\?]+ for function arguments. The class does not
include *, so the extremely common COUNT(*) AS <alias> form is not
detected by getFunctionAliases(…).
When DefaultQueryEnhancer is the active enhancer (native queries,
default setup without the optional jsqlparser dependency),
applySorting(…) then prefixes the alias with the root entity alias,
producing invalid SQL like ORDER BY u.cnt instead of ORDER BY cnt.
Reproducer
@Test
void functionAliasPatternShouldDetectCountStar() {
assertThat(QueryUtils.getFunctionAliases("SELECT COUNT(*) as total FROM User u"))
.containsExactly("total");
}
Current result: empty set. Existing tests in QueryUtilsUnitTests
(around line 550) cover COUNT(1) but never COUNT(*).
Suggested fix
// QueryUtils.java:187
builder.append("\w+\s*\([\w\.,\s'=:;\\?\*]+\)");
Related
I am aware of #2322 and #2441, which reported broader regex limitations
(nested parens, complex casts) and were closed as feedback-provided.
This issue is deliberately narrower: the one-character fix above
addresses the specific COUNT(*) case without attempting to solve the
general parsing problem.
Summary
QueryUtils.FUNCTION_PATTERN(QueryUtils.java:187) uses the characterclass
[\w\.,\s'=:;\\?]+for function arguments. The class does notinclude
*, so the extremely commonCOUNT(*) AS <alias>form is notdetected by
getFunctionAliases(…).When
DefaultQueryEnhanceris the active enhancer (native queries,default setup without the optional
jsqlparserdependency),applySorting(…)then prefixes the alias with the root entity alias,producing invalid SQL like
ORDER BY u.cntinstead ofORDER BY cnt.Reproducer
Current result: empty set. Existing tests in QueryUtilsUnitTests
(around line 550) cover COUNT(1) but never COUNT(*).
Suggested fix
// QueryUtils.java:187
builder.append("\w+\s*\([\w\.,\s'=:;\\?\*]+\)");
Related
I am aware of #2322 and #2441, which reported broader regex limitations
(nested parens, complex casts) and were closed as feedback-provided.
This issue is deliberately narrower: the one-character fix above
addresses the specific COUNT(*) case without attempting to solve the
general parsing problem.