hqbhoho opened a new pull request, #12906:
URL: https://github.com/apache/gravitino/pull/12906

   ### Why are the changes needed?
   
   The Gravitino Trino connector mapped every MySQL 
`TIME`/`DATETIME`/`TIMESTAMP` column to precision 0 in both directions. Reading 
a column with fractional seconds failed with `Expected 0s for digits beyond 
precision 0`, and tables created through Trino silently lost the requested 
precision. The native Trino MySQL connector maps the precision exactly in both 
directions; this PR aligns the Gravitino connector with it, in three commits:
   
   1. **Read path**: map the precision reported by the MySQL catalog to the 
Trino type with the same precision, capped at 6. When the precision is unknown 
(MySQL Connector/J < 8.0.16) the previous precision-0 behavior is kept.
   2. **MySQL catalog**: render `CURRENT_TIMESTAMP(p)` for columns with a 
precision, which MySQL requires (`DATETIME(6) DEFAULT CURRENT_TIMESTAMP` is 
rejected with `Invalid default value`).
   3. **Write path**: pass the Trino precision through, capped at 6, and 
implement `ConnectorMetadata.getSupportedType` so that CTAS from a source with 
a precision above 6 is coerced by Trino instead of failing when the pages are 
written.
   
   Fix: #12903
   
   ### Does this PR introduce _any_ user-facing change?
   
   Yes.
   - MySQL columns with fractional seconds are exposed as `time(p)` / 
`timestamp(p)` / `timestamp(p) with time zone` instead of precision 0.
   - `TIMESTAMP` without a precision, which is `timestamp(3)` in Trino, now 
creates a `DATETIME(3)` column instead of `DATETIME`, matching the native Trino 
MySQL connector. The same applies to `TIME` and `TIMESTAMP WITH TIME ZONE`.
   
   ### How was this patch tested?
   
   - Unit tests in `TestMySQLDataTypeTransformer` (both directions, round trip, 
`getSupportedType`) and `TestMysqlTableOperationsSqlGeneration` 
(`CURRENT_TIMESTAMP(p)` rendering for create table and add column).
   - New integration testset `00016_datetime_precision` covering read of a 
MySQL table with `TIME/DATETIME/TIMESTAMP(3|6)` columns, create/insert/CTAS 
through Trino, and CTAS from a precision-9 source.
   - Updated `00006`/`00011` expectations and the `trino-452-446` patch for the 
tables created through Trino.
   - The `CURRENT_TIMESTAMP(p)` rule was verified against MySQL 8.0.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to