XiaoHongbo-Hope commented on code in PR #936: URL: https://github.com/apache/paimon-rust/pull/936#discussion_r4105793612
########## docs/src/getting-started.md: ########## @@ -276,6 +276,17 @@ refreshes those credentials before expiration, so callers do not need to load the table again. Static `dlf.access-key-id`, `dlf.access-key-secret`, and `dlf.security-token` values are not rotated. +To read credentials managed by another process, use a local token file: + +```rust +options.set(CatalogOptions::DLF_TOKEN_LOADER, "local_file"); +options.set(CatalogOptions::DLF_TOKEN_PATH, "/path/to/token.json"); +``` + +The JSON uses `AccessKeyId`, `AccessKeySecret`, optional `SecurityToken`, and +optional `Expiration` or `ExpirationAt`. Expiring credentials are reloaded from +the file before expiration. Review Comment: > Java's `DLFToken` deserializes `Expiration` and derives its internal expiration time from that string; it does not deserialize `ExpirationAt`. A shared token file containing only `ExpirationAt` will refresh in Rust but be treated as non-expiring in Java, so these fields are not interchangeable. Could you investigate whether we should remove `ExpirationAt` from Rust's DLF token JSON contract? Please check whether existing ECS or PyPaimon payloads rely on it before deciding. If it needs to stay, the docs and tests should make clear that Java-compatible token files must use `Expiration`. Got your point, Need to check with @plusplusjiajia -- 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]
