Map MySQL YEAR column to protocol type 0x0d so yearIsDateType driver property takes effect

[Phixsura]

Fixes #28858.

Changes proposed in this pull request:

• Add MySQLBinaryColumnType.valueOfJDBCType(int, String) and an isYear helper that recognises (Types.DATE, "YEAR") and returns the YEAR enum, mirroring the existing PostgreSQLBinaryColumnType overload pattern.
• Switch the text-protocol column-definition builder (ResponsePacketBuilder) to the new overload, threading QueryHeader#getColumnTypeName() so a MySQL YEAR column is advertised as protocol type 0x0d instead of DATE (0x0a). mysql-connector-j now enters its YEAR branch and the driver-side yearIsDateType=false URL property takes effect.
• ResponsePacketBuilderTest: the parametric case now asserts the on-wire column-type byte for every row, with new rows pinning YEAR → 0x0d and DATE → 0x0a.

The binary (prepared-statement) protocol path has the same gap but needs a paired writer change (java.sql.Date → 2-byte short for MySQLInt2BinaryProtocolValue); sending that as a separate follow-up rather than crammed into this one.

---

Before committing this PR, I'm sure that I have checked the following options:

• My code follows the code of conduct of this project.
• I have self-reviewed the commit code.
• I have (or in comment I request) added corresponding labels for the pull request.
• I have passed maven check locally for the affected modules (spotless, checkstyle, unit tests).
• I have made corresponding changes to the documentation.
• I have added corresponding unit tests for my changes.
• I have updated the Release Notes of the current development version. For more details, see Update Release Note

[terrymanu]

Decision

Merge Verdict: Not Mergeable

Reviewed Scope: PR latest head 40b24ef; 5 changed files in database/protocol/dialect/mysql, proxy/frontend/dialect/mysql, and RELEASE-NOTES.md.
Not Reviewed Scope: Full runtime E2E execution against a live Proxy/MySQL instance was not run locally.
Need Expert Review: MySQL Proxy protocol/prepared-statement reviewer after the binary path is addressed.
Positive Feedback

The text-protocol direction is right: ResponsePacketBuilder now passes columnTypeName, and the new tests cover the adjacent YEAR vs DATE counterexample. This aligns with MySQL/Connector-J behavior: YEAR is a distinct MySQL field type, and Connector/J maps yearIsDateType=false to java.sql.Short.

Sources: PR #38697, Issue #28858, MySQL Column Definition, Connector/J YEAR handling.

Major Issues

Prepared-statement/binary path still has the same YEAR mapping gap.

The PR fixes ResponsePacketBuilder for text COM_QUERY, but MySQLProjectionMetadataResolver still builds prepared-statement projection metadata with MySQLBinaryColumnType.valueOfJDBCType(queryHeader.getColumnType()), and MySQLComStmtPrepareExecutor still uses JDBC type alone for local metadata paths. MySQLComStmtExecuteExecutor also creates BinaryCell from JDBC type only.

Risk: clients using server-side prepared statements can still receive DATE metadata for a YEAR column, so yearIsDateType=false remains ineffective on that path. MySQL binary resultsets also encode MYSQL_TYPE_YEAR as an integer value, not the date binary shape, so this needs metadata plus row-writer validation.

Recommended action: thread columnTypeName through all MySQL prepared metadata and binary row paths, then add direct regression tests for YEAR and DATE in COM_STMT_PREPARE / COM_STMT_EXECUTE.

Current validation proves the packet byte only, not the original client-visible symptom.

The added ResponsePacketBuilderTest confirms the text column-definition byte, but it does not validate the full chain: backend JDBC metadata -> QueryHeader -> row payload -> Connector/J ResultSet.getObject() with yearIsDateType=false.

Risk: the original issue is about returned Java type, and the PR body itself says another protocol path remains open. Please add either an integration reproduction or narrowly scoped protocol tests that prove both metadata and row value behavior for YEAR, including the adjacent DATE case.

Release note/title overstate the fix while binary protocol is explicitly deferred.

RELEASE-NOTES.md says the driver property takes effect for Proxy generally, but the PR text says binary protocol has the same gap and is deferred. Please either complete that path in this PR or narrow the wording and avoid closing the whole issue as fully fixed.

Next Steps

Fix or explicitly rescope the server-prepared path.
Add one-to-one tests for text Statement, server-prepared PreparedStatement, YEAR, and adjacent DATE.
Include client flags such as useServerPrepStmts=true in the prepared-statement validation.
Re-run scoped Maven with dependencies, for example ./mvnw -pl proxy/frontend/dialect/mysql,database/protocol/dialect/mysql -am -DskipITs -Dspotless.skip=true -Dtest=ResponsePacketBuilderTest,MySQLBinaryColumnTypeTest test.

[terrymanu]

Decision

• Merge Verdict: Not Mergeable
• Reviewed Scope: Latest PR head acdfaaac3acf6ede51749d63281d942c6a0675d2; Proxy MySQL text and binary query paths; ColumnMetaData / ShardingSphereColumn / YAML metadata propagation; MySQL metadata loader; related sharding/encrypt/broadcast/single metadata revise path by code inspection; PR #38697 and issue #28858; MySQL official YEAR / Connector/J / binary protocol docs.
• Not Reviewed Scope: No local Maven run on a checked-out PR worktree; no live Proxy + MySQL Connector/J reproduction; no cluster-registry upgrade test; MariaDB client behavior not validated.
• Need Expert Review: Yes, a MySQL protocol / Connector/J reviewer should re-check the text and binary result semantics after the fixes.

Positive Feedback

• The direction is right: distinguishing MySQL YEAR from DATE by using columnTypeName is aligned with Connector/J's documented yearIsDateType behavior.
• The binary-row adjustment toward a 2-byte YEAR value matches MySQL's binary protocol shape for MYSQL_TYPE_YEAR.

Major Issues

• [Blocking] columnTypeName is dropped by shared metadata revision (infra/common/src/main/java/org/apache/shardingsphere/infra/metadata/database/schema/reviser/column/ColumnReviseEngine.java:59)

  • Symptom: This PR adds ColumnMetaData.columnTypeName and ShardingSphereColumn.columnTypeName, and MySQLMetaDataLoader fills it from DATA_TYPE; however, ColumnReviseEngine reconstructs every revised column with the old 8-argument constructor, so the new field becomes null.
  • Risk: TableMetaDataReviseEngine invokes this path for rule-based metadata revision, and sharding/encrypt/broadcast/single all have MetaDataReviseEntry implementations. After revision, MySQLComStmtPrepareExecutor reads column.getColumnTypeName() at lines 145, 170, and 207, so a MySQL YEAR column can fall back to protocol DATE in prepared-statement metadata under feature-rule topologies. That leaves a shared-path regression in the same Proxy + MySQL metadata area as the linked issue.
  • Action: Please preserve each.getColumnTypeName() when rebuilding ColumnMetaData, and add regression coverage for a MySQL YEAR column after metadata revision, at least through a sharding-rule metadata path that reaches COM_STMT_PREPARE.

• [Blocking] The original text-query symptom is still only metadata-tested, not row-path-tested (database/protocol/dialect/mysql/src/main/java/org/apache/shardingsphere/database/protocol/mysql/packet/command/query/text/MySQLTextResultSetRowPacket.java:60)

  • Symptom: ResponsePacketBuilderTest now checks the column-definition type byte, but the issue uses Statement.executeQuery(...). That path still passes raw row values into MySQLTextResultSetRowPacket, whose writer serializes non-special values with data.toString() and has no column-type context. For a backend java.sql.Date value, that can emit YYYY-MM-DD, while MySQL documents YEAR display as YYYY.
  • Risk: Connector/J documents that yearIsDateType=false maps YEAR to java.sql.Short, but the PR does not prove the original Proxy text protocol path returns Short; it proves only that the metadata byte changes. This is unresolved root-cause evidence, especially for YEAR zero-value behavior where Connector/J has documented special cases.
  • Action: Please add a regression that exercises the original COM_QUERY path end-to-end, or an equivalent packet-level test with row payload validation, proving YEAR returns a Short with yearIsDateType=false while normal DATE remains date-like. If the text writer emits the wrong value, thread column type context into row serialization or adjust YEAR values before writing.

Newly Introduced Issues

• The metadata propagation gap above is introduced by adding a new shared metadata field without preserving it in the shared metadata-revision path.

Next Steps

• Preserve columnTypeName in ColumnReviseEngine and add focused tests for revised metadata.
• Add original-issue coverage for Proxy MySQL COM_QUERY with yearIsDateType=false.
• Add a prepared-statement regression where local metadata is used after sharding/encrypt/single metadata revision.
• Keep DATE counterexamples in the tests so DATE does not become YEAR accidentally.
• Re-run scoped checks with dependent modules included, for example affected-module tests with -am, then Spotless and Checkstyle.

Evidence Supplement

• PR evidence: apache/shardingsphere#38697, latest head acdfaaac3acf6ede51749d63281d942c6a0675d2, 16 files changed.
• Issue evidence: apache/shardingsphere#28858 reports Proxy + MySQL Connector/J 8 with yearIsDateType=false.
• Official behavior evidence: MySQL Connector/J documents yearIsDateType=false mapping YEAR to java.sql.Short; MySQL documents YEAR display as YYYY; MySQL binary protocol documents MYSQL_TYPE_YEAR as a 2-byte integer.
• CI evidence: GitHub API reported 83 successful check runs on the latest head, but CI success does not close the root-cause and blast-radius gaps above.
• Local commands used for review: git fetch apache pull/38697/head:refs/remotes/apache/pr/38697 --no-tags exit 0; git diff --name-status 579de83cf84b1c3523380b845781a45a0f54c13a...refs/remotes/apache/pr/38697 exit 0; git show / git grep inspections exit 0.

[terrymanu]

Decision

• Merge Verdict: Not Mergeable
• Reviewed Scope: Latest PR head 8125cf9daeceb2de8439c263ca0d2f3d2279c170; MySQL Proxy text and binary query paths; prepared-statement metadata paths; ColumnMetaData / ShardingSphereColumn / YAML metadata propagation; sharding metadata revise test; release note; prior GitHub-visible review feedback.
• Not Reviewed Scope: No live Proxy + MySQL Connector/J reproduction; no Maven test run; no cluster-registry upgrade test; no GitHub Actions / check-run evidence used.
• Need Expert Review: Yes, MySQL protocol / Connector-J behavior should be rechecked after the remaining fixes.

Positive Feedback

• The latest revisions move in the right direction: columnTypeName is now preserved through ColumnReviseEngine, the text COM_QUERY row path handles Date-backed YEAR, and the binary path now advertises MYSQL_TYPE_YEAR for (Types.DATE, "YEAR").

Major Issues

• [Blocking] Binary YEAR row serialization still fails for Short values (proxy/frontend/dialect/mysql/src/main/java/org/apache/shardingsphere/proxy/frontend/mysql/command/query/binary/execute/MySQLComStmtExecuteExecutor.java:164)

  • Symptom: The new binary-row adjustment converts only java.sql.Date to an integer year. If the backend or merged result already provides Short, it is passed unchanged into BinaryCell; MySQLInt2BinaryProtocolValue.write(...) then casts the value to Integer at database/protocol/dialect/mysql/src/main/java/org/apache/shardingsphere/database/protocol/mysql/packet/command/query/binary/execute/protocol/MySQLInt2BinaryProtocolValue.java:36.
  • Risk: Connector/J documents that yearIsDateType=false maps YEAR to java.sql.Short, and JDBCStreamQueryResult can return raw resultSet.getObject(...) at infra/executor/src/main/java/org/apache/shardingsphere/infra/executor/sql/execute/result/query/impl/driver/jdbc/type/stream/JDBCStreamQueryResult.java:123. A valid YEAR value can therefore hit the prepared/binary result path as Short and fail with ClassCastException instead of returning a row.
  • Action: Please normalize YEAR values from any Number to an int before writing the binary packet, and add a regression test using new QueryResponseCell(Types.DATE, Short.valueOf((short) 1925), "YEAR"), alongside the existing Date and adjacent DATE cases.

• [Blocking] COM_STMT_PREPARE YEAR metadata is changed but still not directly validated (proxy/frontend/dialect/mysql/src/main/java/org/apache/shardingsphere/proxy/frontend/mysql/command/query/binary/prepare/MySQLComStmtPrepareExecutor.java:145)

  • Symptom: The PR now uses column.getColumnTypeName() for parameter marker metadata and local projection metadata at lines 145 and 207, and also changes the JDBC-probe resolver. However, MySQLComStmtPrepareExecutorTest still uses only id, name, and age metadata in its schema fixture at proxy/frontend/dialect/mysql/src/test/java/org/apache/shardingsphere/proxy/frontend/mysql/command/query/binary/prepare/MySQLComStmtPrepareExecutorTest.java:347, and there is no YEAR case in the prepared test package.
  • Risk: The earlier blocker was specifically about the server-prepared path. Current tests cover text response packets and COM_STMT_EXECUTE row bytes, but they do not prove that COM_STMT_PREPARE returns type byte 0x0d for SELECT t_year ..., WHERE t_year = ?, or the JDBC-probe metadata path.
  • Action: Please add direct prepared-statement tests for local schema metadata and probe metadata, asserting YEAR -> 0x0d and the adjacent DATE -> 0x0a counterexample.

Next Steps

• Normalize numeric YEAR row values in the binary writer before MySQLInt2BinaryProtocolValue sees them.
• Add COM_STMT_PREPARE tests for YEAR projection metadata and parameter marker metadata.
• Keep the existing DATE counterexamples so normal dates do not accidentally become YEAR.
• After fixes, run affected-module tests with dependencies, for example ./mvnw -pl proxy/frontend/dialect/mysql,database/protocol/dialect/mysql,infra/common,features/sharding/core,database/connector/dialect/mysql -am -DskipITs -Dspotless.skip=true -Dtest=MySQLComStmtPrepareExecutorTest,MySQLComStmtExecuteExecutorTest,MySQLComQueryPacketExecutorTest,ResponsePacketBuilderTest,MySQLBinaryColumnTypeTest,ColumnReviseEngineTest,ShardingMetaDataReviseEntryTest,MySQLMetaDataLoaderTest test.

Multi-Round Comparison

• Fixed: The shared metadata-revision loss from the previous review is addressed by preserving each.getColumnTypeName() in ColumnReviseEngine, with an added sharding revise-path test.
• Partially fixed: The binary/prepared path now threads columnTypeName and tests Date-backed binary rows, but it still misses the valid Short producer path.
• Partially fixed: Text COM_QUERY now validates row payload for a Date-backed YEAR; this no longer remains the primary blocker in the latest head.
• Not fixed: Direct COM_STMT_PREPARE validation for YEAR metadata is still missing.

Evidence Supplement

• PR evidence: apache/shardingsphere#38697, latest head 8125cf9daeceb2de8439c263ca0d2f3d2279c170.
• Issue evidence: apache/shardingsphere#28858 reports Proxy + MySQL Connector/J 8 with yearIsDateType=false, expecting Short.
• Official behavior evidence: Connector/J YEAR handling documents the yearIsDateType=false mapping; MySQL protocol field types list MYSQL_TYPE_YEAR separately from MYSQL_TYPE_DATE.
• Local inspection commands: git fetch apache pull/38697/head:refs/remotes/apache/pr/38697 exit 0; git diff --name-only apache/master...apache/pr/38697 exit 0; git grep -n "YEAR\\|year" apache/pr/38697 -- proxy/frontend/dialect/mysql/src/test/java/org/apache/shardingsphere/proxy/frontend/mysql/command/query/binary/prepare || true exit 0 with no prepared-path YEAR tests found.
• Local Maven verification was not run because the static review found blocking functional and coverage gaps first.

[Phixsura]

B1 已修。MySQLComStmtExecuteExecutor#adjustValueForBinaryColumnType 现在把任何 Number 形态的 YEAR 在写包前规范成 int,Date / Short / Integer / Long 都走同一路径,binary protocol 写包不会再因为 MySQLInt2BinaryProtocolValue:37 的 (Integer) value cast 抛 ClassCastException。回归测试 MySQLComStmtExecuteExecutorTest#assertYearColumnFromShortValueEncodedAsShort 用 new QueryResponseCell(Types.DATE, Short.valueOf((short) 1925), "YEAR") pin 住 Short 路径,packet 体读出 0x00 0x00 + LE 1925。撤回 Number 分支后该用例报 class java.lang.Short cannot be cast to class java.lang.Integer,跟你描述的失败模式一字不差。

B2 已修。MySQLComStmtPrepareExecutorTest#createDatabase schema fixture 增了 birth_year (Types.DATE, "YEAR") 和邻接的 birth_date (Types.DATE, "DATE") 两列,显式贯穿 column.getColumnTypeName()。新增三条 prepare 路径用例:

• assertPrepareSelectYearAndDateColumnsExposesProtocolTypesFromLocalSchema 走 MySQLComStmtPrepareExecutor:207 (local schema projection),断言 YEAR projection column type = MySQLBinaryColumnType.YEAR.getValue() (0x0d),邻接 DATE projection = 0x0a。
• assertPrepareSelectWithYearAndDateParameterMarkersCarriesProtocolTypes 走 MySQLComStmtPrepareExecutor:145 (parameter marker),断言 parameterColumnTypes 严格等于 [YEAR, DATE]。
• assertPrepareSelectExpressionStatementByProbeReturnsYearProtocolType 走 MySQLProjectionMetadataResolver:100 (probe metadata),mock ResultSetMetaData.getColumnType=Types.DATE + getColumnTypeName="YEAR",断言 projection column type = 0x0d,跟邻位 assertPrepareSelectExpressionStatementByProbe 的 BIGINT 反例对照。

Head c8998e46add。./mvnw test -pl proxy/frontend/dialect/mysql 166/166 全绿,spotless:check / checkstyle:check 干净。

git diff --check 还报 trailing whitespace,但项目 spotless 强制方法间空行带 4 空格缩进 (./mvnw spotless:check 失败如果把那 4 空格去掉),master 上既有文件就是这个格式,所以这条本仓库的 spotless 跟 git diff --check 不兼容,我没法在不破 spotless 的前提下让 git diff --check 干净。

[terrymanu]

Please resolve conflict first

[terrymanu]

Decision

• Merge Verdict: Not Mergeable
• Reviewed Scope: Latest PR head 1e42d9b7fa94debfb504fdcec82cf1c4a70f0212; local merge-base a9ac265ad4adcc247a8af27f1febca026e6cc8d4; GitHub /pulls/38697/files matched the local 22-file triple-dot diff exactly. Reviewed Proxy MySQL text/binary query paths, prepared metadata, MySQL protocol type mapping, MySQL metadata loading, shared schema metadata/YAML propagation, sharding metadata revision coverage, release note, issue #28858, and prior GitHub-visible review feedback.
• Not Reviewed Scope: No live Proxy + MySQL Connector/J reproduction, no cluster-registry upgrade test, and no local Maven test run because the static review found an unresolved functional boundary first. GitHub Actions / CI status was not used.
• Need Expert Review: Yes, MySQL protocol / Connector-J semantics should be rechecked after the remaining YEAR zero-value fix.

Positive Feedback

• The latest revision fixes several previous blockers: columnTypeName is preserved through shared metadata revision, COM_STMT_PREPARE now has direct YEAR vs DATE metadata tests, and binary row writing now normalizes Number YEAR values before the 2-byte protocol writer.
• Mapping (Types.DATE, "YEAR") to MYSQL_TYPE_YEAR is directionally correct and matches the documented Connector/J yearIsDateType=false goal.

Major Issues

• [Blocking] YEAR zero values can still be returned with the wrong client-visible value (proxy/frontend/dialect/mysql/src/main/java/org/apache/shardingsphere/proxy/frontend/mysql/command/query/text/query/MySQLComQueryPacketExecutor.java:147)
  • Symptom: The new text path only converts java.sql.Date YEAR values to String.format("%04d", dateYear). If the row value is already a Number, MySQLTextResultSetRowPacket still falls through to data.toString() at database/protocol/dialect/mysql/src/main/java/org/apache/shardingsphere/database/protocol/mysql/packet/command/query/text/MySQLTextResultSetRowPacket.java:89, so Short.valueOf((short) 0) is sent as "0" instead of MySQL's YEAR display value "0000". On the default backend path, MySQLResultSetMapper#getDateValue reads YEAR via resultSet.getObject(...) at database/connector/dialect/mysql/src/main/java/org/apache/shardingsphere/database/connector/mysql/resultset/MySQLResultSetMapper.java:38, and the MySQL default query properties do not set backend yearIsDateType=false at database/connector/dialect/mysql/src/main/java/org/apache/shardingsphere/database/connector/mysql/jdbcurl/MySQLDefaultQueryPropertiesProvider.java:31; therefore a backend YEAR 0000 can already be collapsed by Connector/J into Date(2000-01-01). The binary path has the same Date-to-year collapse at proxy/frontend/dialect/mysql/src/main/java/org/apache/shardingsphere/proxy/frontend/mysql/command/query/binary/execute/MySQLComStmtExecuteExecutor.java:164.
  • Risk: The original issue is about Connector/J client-visible YEAR behavior. Official Connector/J docs say yearIsDateType=false maps YEAR to java.sql.Short, and its zero-value rules distinguish numeric 0 from 2000; MySQL docs also say YEAR displays in YYYY format and includes 0000. This PR can make YEAR 0000 arrive as Short 2000, or as text "0" on the Number-backed path, so the root-cause repair is still incomplete for a valid boundary value.
  • Action: Please preserve YEAR's raw value before it is collapsed into java.sql.Date, or otherwise normalize YEAR rows from both Date and Number forms to native MySQL semantics. Add direct regressions for YEAR 0000, YEAR 2000, and adjacent DATE on both COM_QUERY and COM_STMT_EXECUTE; text protocol should emit 0000 for zero YEAR, and binary protocol should write the 2-byte integer 0.

Newly Introduced Issues

• The zero-value drift is introduced by the new YEAR row conversion logic: the patch now advertises MYSQL_TYPE_YEAR, but the row payload conversion still does not prove native YEAR zero semantics.

Next Steps

• Add zero-value tests for text and binary YEAR rows, including Short 0, Date(2000-01-01), real YEAR 2000, and adjacent normal DATE.
• Adjust the MySQL YEAR extraction/conversion path so 0000 remains distinguishable from 2000.
• Keep the existing YEAR vs DATE metadata tests; they are useful and should remain.
• After the fix, run scoped verification with dependencies, for example: ./mvnw -pl proxy/frontend/dialect/mysql,database/protocol/dialect/mysql,database/connector/dialect/mysql,infra/common,features/sharding/core -am -DskipITs -Dspotless.skip=true -Dtest=MySQLComQueryPacketExecutorTest,MySQLComStmtExecuteExecutorTest,MySQLComStmtPrepareExecutorTest,ResponsePacketBuilderTest,MySQLBinaryColumnTypeTest,MySQLMetaDataLoaderTest,ColumnReviseEngineTest,ShardingMetaDataReviseEntryTest test, then run the repository Spotless and Checkstyle gates.

Multi-Round Comparison

• Fixed: The shared metadata-revision loss is addressed by preserving columnTypeName in ColumnReviseEngine.
• Fixed: The previous Short binary-row ClassCastException risk is addressed by normalizing Number YEAR values.
• Fixed: Direct COM_STMT_PREPARE YEAR metadata coverage was added for local schema, parameter marker, and probe metadata paths.
• Newly introduced / unresolved: Valid zero YEAR semantics remain unproven and can still diverge from native MySQL + Connector/J behavior.

Evidence Supplement

• Issue evidence: apache/shardingsphere#28858 targets ShardingSphere-Proxy + MySQL Connector/J with yearIsDateType=false.
• Official behavior evidence: Connector/J YEAR handling, MySQL YEAR type, and MySQL binary protocol YEAR as int<2>.
• Local boundary evidence: git fetch apache master +pull/38697/head:refs/remotes/apache/pr/38697 exit 0; local 22-file diff matched GitHub /pulls/38697/files; git grep -n "computeIfAbsent" over changed files found no hot-path computeIfAbsent usage.

[terrymanu]

Please resolve conflicts first

[terrymanu]

Hi @Phixsura, thanks again for the continued updates on this PR.

The fix direction looks reasonable, and the latest revisions have addressed several previous YEAR metadata and row-serialization concerns. However, this PR is currently not ready for review or merge because it has conflicts with the target branch, and the latest maintainer feedback asked to resolve conflicts first.

Could you please rebase this PR and resolve the conflicts? After that, we can continue the focused review on the MySQL YEAR protocol behavior. To keep the review queue clear, we may close this PR soon due to inactivity if there is still no response or update.

Thanks again for your contribution.