laserninja opened a new pull request, #10536: URL: https://github.com/apache/gravitino/pull/10536
### What changes were proposed in this pull request? Optimize the ETag-based freshness check in `loadTable` by leveraging `SupportsMetadataLocation` to resolve the metadata file location cheaply without loading full table metadata. When the client sends `If-None-Match` and the catalog supports it, the server can return `304 Not Modified` without the cost of a full `loadTable` call. Also fixes ETag consistency between `createTable`/`updateTable` and `loadTable`: ETags from create and update now include the default `snapshots` value (`"all"`), matching the default `loadTable` ETag. This allows clients to reuse ETags across endpoints as specified by the Iceberg REST spec. ### Why are the changes needed? 1. **Performance**: The original implementation always performs a full `loadTable` before comparing ETags. For read-heavy workloads where clients already have fresh metadata (ETag matches), this full load is wasted. By using `SupportsMetadataLocation` (already implemented for JDBC and Hive catalogs), we can compare ETags via a lightweight metadata location query and skip the full load entirely. 2. **ETag consistency** (as reported by @FANNG1 in #10498): `createTable` returned an ETag derived from `metadataLocation` only, while `loadTable` derived its ETag from `metadataLocation + snapshots`. For the default `snapshots=all` path, these values differed, so a client that reuses the ETag from create would never get `304 Not Modified` on a subsequent unchanged `loadTable`. Follow-up to: #10498 ### Does this PR introduce _any_ user-facing change? No user-facing API changes. The ETag values may differ from the previous implementation due to the consistency fix, but this is transparent to clients — they will simply get fresh ETags on the next request. ### How was this patch tested? - Added `testCreateTableETagMatchesLoadTableETag`: Verifies that the ETag from `createTable` matches the default `loadTable` ETag, and that it produces `304` on a subsequent conditional load. - Added `testUpdateTableETagMatchesLoadTableETag`: Same verification for `updateTable`. - All existing ETag tests continue to pass (8 tests covering ETag presence, 304 matching, ETag changes after update, consistency, and snapshot-dependent ETags). -- 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]
