nevzheng opened a new issue, #11983: URL: https://github.com/apache/gravitino/issues/11983
What would you like to be improved? On #11927, Mark asked for test coverage of adjacent Iceberg types (V2 UUID; struct/array/map), verified across both the IRC/REST and native interfaces — https://github.com/apache/gravitino/issues/11927#issuecomment-4909915786 Following up on that: the Iceberg catalog integration test (`CatalogIcebergBaseIT`, run by both `CatalogIcebergRestIT` and `CatalogIcebergHiveIT`) only round-trips a subset of V2 column types end-to-end through a live backend — `int`, `long`, `date`, `string`, `struct`, `time`, `timestamp`. The remaining V2 types — `boolean`, `float`, `double`, `uuid`, `fixed`, `binary`, `decimal`, `list`, `map` — are unit-tested at the converter level (`TestConvertUtil`) but are never created and loaded through the real REST/IRC and Hive backends. That leaves the backend/serialization path for these types (notably the parameterized/nested ones — `decimal` precision/scale, `fixed` length, `list`, `map`) unverified end-to-end. How should we improve? Add an integration test to `CatalogIcebergBaseIT` that creates a table with the remaining V2 types through the native metadata API, loads it back, and asserts both that the Gravitino types round-trip unchanged and that the underlying Iceberg schema stores the expected Iceberg types. As all are valid V2 types, it runs on both backends (REST/IRC and Hive) with no assumptions. -- 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]
