diqiu50 opened a new issue, #13032:
URL: https://github.com/apache/gravitino/issues/13032
### Version
main branch
### Describe what's wrong
Loading a MySQL table via the jdbc-mysql catalog loses type information for
several column types:
- `VARBINARY(100)`, `ENUM('a','b','c')`, `SET('x','y','z')` are reported as
a bare external type (e.g. `external "VARBINARY"`), dropping the
length/enumerated values.
- `BIT(8)` and `BINARY(16)` both collapse to the same widthless `binary`
type, so different declared widths become indistinguishable in what Gravitino
reports.
### Error message and/or stacktrace
Not applicable — this is a silent data-loss issue, not a crash.
### How to reproduce
1. Create a MySQL table:
```sql
CREATE TABLE t (
c_varbinary VARBINARY(100),
c_enum ENUM('a','b','c'),
c_set SET('x','y','z'),
c_bit BIT(8),
c_binary BINARY(16)
);
```
2. Register the schema under a jdbc-mysql catalog in Gravitino and load the
table.
3. Observe that `c_varbinary`/`c_enum`/`c_set` report as `external
"VARBINARY"`/`external "ENUM"`/`external "SET"` (parameters dropped), and
`c_bit`/`c_binary` both report as plain `binary` (width lost, indistinguishable
from each other).
### Additional context
MySQL's `information_schema.columns.COLUMN_TYPE` carries the full
declaration (e.g. `varbinary(100)`, `enum('a','b','c')`), while the connector
currently only reads `DATA_TYPE`/`TYPE_NAME`, which is the bare type name. The
full declaration should be used for the external catalogString so the source
type survives, and BIT/BINARY should preserve width information.
--
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]
