Skip to content

fix(admin): use two-argument CONCAT for Oracle operation-log searches (#7738) - #7756

Merged
Aias00 merged 1 commit into
apache:masterfrom
konlue:fix/oracle-log-concat
Oct 19, 2026
Merged

Aias00 merged 1 commit into
apache:masterfrom
konlue:fix/oracle-log-concat

Conversation

@konlue

@konlue konlue commented Oct 17, 2026

Copy link
Copy Markdown
Contributor

Fixes #7738.

Summary

Operation-log keyword/exclusion searches are generated by the shared selectByCondition statement with a three-argument concat('%', #{...}, '%'). Oracle only supports two-argument CONCAT, so filtered searches fail on Oracle deployments.

Modifications

  • Rewrite both predicates as nested two-argument calls: concat(concat('%', #{...}), '%'), for condition.keyword and condition.excluded.
  • Add a MyBatis statement-shape test resolved with databaseId="oracle".

Verifying this change

  • New OperationRecordLogConcatSqlTest: parses the mapper under databaseId="oracle" with non-empty keyword/excluded and asserts the SQL uses the nested two-argument form and never the three-argument form. Fails on the previous statement (concat('%',?,'%')), passes with the fix.

  • Targeted test passes:

    ./mvnw -B -ntp -pl shenyu-admin test -Dtest=OperationRecordLogConcatSqlTest

    1/1 green.

  • H2 functional regression passes:

    ./mvnw -B -ntp -pl shenyu-admin test -Dtest=OperationRecordLogMapperTest

    2/2 green.

  • Checkstyle passes:

    ./mvnw -B -ntp -pl shenyu-admin checkstyle:check

    clean.

Notes

Only the expression nesting changes; wildcard placement and LIKE/NOT LIKE semantics stay identical on every dialect. Nested CONCAT is supported by Oracle, MySQL, PostgreSQL and H2 alike, so no dialect-specific statement is needed.

@Aias00 Aias00 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Verified the fix is complete, not just locally correct.

Evidence

  • Oracle's CONCAT accepts exactly two arguments, so concat('%', #{...}, '%') raises ORA-00909. The nested form is the standard workaround and is valid on MySQL, PostgreSQL and H2 as well, so keeping one statement without a databaseId variant is the right call here.
  • Scope is complete: concat( appears in exactly one mapper in the repository (operation-record-log-sqlmap.xml, both the keyword and the excluded predicate), and this PR fixes both. A repo-wide grep over *.xml finds no remaining three-argument concat.
  • Semantics unchanged: '%' || kw || '%' is identical to concat(concat('%', kw), '%'); wildcard placement, LIKE/NOT LIKE and the binds stay parameterised.
  • The statement-shape test has a real red-green: it asserts the absence of concat('%',?,'%') as well as the presence of the nested form, so it cannot pass vacuously on master.

Non-blocking

  1. Two observations for the file rather than this PR: a % inside the search term is still treated as a wildcard (pre-existing LIKE semantics), and the same two predicates are duplicated between selectByCondition and the Oracle selectLimit variant — if either ever changes, both places need it.

I re-ran the shape test mentally against the generic statement too: because the shared statement has no databaseId, it still resolves under databaseId="oracle", so the test is exercising the statement users actually hit on Oracle.

@Aias00
Aias00 merged commit 502f107 into apache:master Oct 19, 2026
55 of 65 checks passed
@Aias00 Aias00 added this to the 2.7.2 milestone Nov 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Oracle operation-log keyword searches generate unsupported three-argument CONCAT

2 participants