hqbhoho opened a new issue, #12903:
URL: https://github.com/apache/gravitino/issues/12903
### Version
main branch
### Describe what's wrong
#6657 made the MySQL catalog report the fractional seconds precision of
TIME/DATETIME/TIMESTAMP columns, but the Trino connector never picked it up:
`MySQLDataTypeTransformer.getTrinoType` still maps every Gravitino TIMESTAMP to
Trino `timestamp(0)` (or `timestamp(0) with time zone`) and every TIME to
`time(0)`, regardless of the precision carried by the Gravitino type.
The internal Trino MySQL connector produces pages with the real column
precision, so the declared type and the page type disagree, and `SELECT` on any
DATETIME(p)/TIMESTAMP(p)/TIME(p) column with p > 0 fails.
This is the Trino side of #6656, which was closed by #6657 without touching
the connector. #8216 later only changed the reverse direction
(`getGravitinoType`).
### Error message and/or stacktrace
```
Could not serialize column 'created_at' of type 'timestamp(0)'
Caused by: java.lang.IllegalArgumentException: Expected 0s for digits beyond
precision 0: epochMicros = 1679540780487000
at io.trino.spi.type.SqlTimestamp.newInstance
at io.trino.spi.type.ShortTimestampType.getObjectValue
```
### How to reproduce
1. In MySQL: `CREATE TABLE t (id INT, created_at DATETIME(6)); INSERT INTO t
VALUES (1, '2025-07-04 14:30:00.123456');`
2. Create a jdbc-mysql catalog in Gravitino and load it in Trino through the
Gravitino connector (MySQL Connector/J >= 8.0.16 on the Gravitino server so the
precision is reported).
3. `SHOW CREATE TABLE` shows `created_at` as `timestamp(0)`; `SELECT * FROM
t` fails with the error above.
### Additional context
Expected: the column is exposed as `timestamp(6)` and the query succeeds,
matching the native Trino MySQL connector and the PostgreSQL transformer in
this repo, which already maps the precision.
Not in scope here: `getGravitinoType` still forces precision 0 when creating
tables through Trino (kept from #8216 for compatibility). Passing the precision
through on the write side requires the MySQL catalog to render
`CURRENT_TIMESTAMP(p)` default values and should be tracked separately under
#7331.
--
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]
