fix(admin): tag_relation updateByPrimaryKeySelective sets non-existent name column

[yangjj-iso]

Fixes #6830

Problem

tag-relation-sqlmap.xml line 125 emits name = #{apiId, jdbcType=VARCHAR} in the apiId branch of updateByPrimaryKeySelective, but tag_relation only has the columns id, api_id, tag_id, date_created and date_updated. There is no name column.

This is reachable from the REST layer: PUT /tag-relation/id/{id} → TagRelationController.updateTagRelation → TagRelationServiceImpl.update → TagRelationDO.buildTagRelationDO, which always populates apiId from the DTO. Whenever the request body carries an apiId, the <if> branch fires and the statement becomes UPDATE tag_relation SET name = ? ..., which fails with a SQL grammar error instead of performing the update.

The sibling updateByPrimaryKey in the same mapper (line 137) already uses api_id, which confirms this is a copy-paste defect rather than intent.

Change

• tag-relation-sqlmap.xml: name → api_id in updateByPrimaryKeySelective.
• TagRelationMapperTest: add testUpdateByPrimaryKeySelective. This was the only TagRelationMapper method the test class did not cover, which is why the defect went unnoticed. The test inserts a row, updates apiId, asserts the new value is persisted, and deletes the row so it does not perturb the sibling tests that assert on row counts.

Verification

Run against JDK 17 (matching the CI matrix):

With the fix applied:

[INFO] You have 0 Checkstyle violations.
[INFO] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0 - in org.apache.shenyu.admin.mapper.TagRelationMapperTest
[INFO] BUILD SUCCESS

With the mapper change reverted and only the new test in place, to confirm the test actually pins the defect:

[ERROR] TagRelationMapperTest.testUpdateByPrimaryKeySelective:96 » BadSqlGrammar
### Cause: org.h2.jdbc.JdbcSQLSyntaxErrorException: Column "NAME" not found

Make sure that:

• You have read the contribution guidelines.
• You submit test cases (unit or integration tests) that back your changes.
• Your local test passed. Scope note: I ran ./mvnw -pl shenyu-admin -am -DskipTests install followed by ./mvnw -pl shenyu-admin test -Dtest=TagRelationMapperTest with Checkstyle enabled, rather than a full-reactor clean install. The change touches a single MyBatis statement in shenyu-admin, so no other module is affected.

[Aias00]

Review: #6907 — fix(admin): tag_relation updateByPrimaryKeySelective sets non-existent name column

Verdict: ✅ Approve

Textbook copy-paste bug fix for #6830.

What's correct

• The column genuinely doesn't exist. I verified the tag_relation DDL (db/init/oracle/schema.sql): columns are id, api_id, tag_id, date_created, date_updated. There is no name. So UPDATE tag_relation SET name = ? always threw a BadSqlGrammar whenever a request carried an apiId — exactly the reported failure on PUT /tag-relation/id/{id}.
• Fix targets the right column. name → api_id matches the sibling updateByPrimaryKey in the same mapper, which already uses api_id. That sibling statement is the strongest evidence this was a copy-paste defect, not intent.
• Regression test pins the defect. testUpdateByPrimaryKeySelective was the only uncovered mapper method (which is why the bug slipped through). It inserts a row, updates apiId, asserts persistence, then deletes the row to avoid perturbing the count-based sibling tests. The PR description shows it failing with BadSqlGrammar when the mapper change is reverted — proper proof that the test is meaningful.

Non-blocking suggestions

1. This same name = #{apiId} typo pattern could exist in other *sqlmap.xml files (the PR notes it's a copy-paste class of bug). A quick repo-wide grep for name = #{...Id against tables without a name column would be a cheap follow-up to catch siblings — but that's out of scope for this PR.
2. buildTagRelationDO always populates apiId from the DTO, so the <if test="apiId != null"> branch fires on essentially every update. Not a problem with this fix, just noting the branch is effectively always-on.

Verdict

Approving. One-line, verifiably-correct, test-backed. Merge as-is.