liurenjie1024 commented on issue #98: URL: https://github.com/apache/iceberg-rust/issues/98#issuecomment-1818147736
Hi, @my-vegetable-has-exploded Sorry for the confusion. `UnboundPartitionSpec` has two important use cases: 1. In [rest api's definition](https://github.com/apache/iceberg/blob/a66166326d0ab3ee54065ac3accd6a3a1c3b89d9/open-api/rest-catalog-open-api.yaml#L1466). In this definition, the `specId` of `PartitionSpec`, `field_id` of `PartitionFieldSpec` are all optional in request(they are [readonly](https://swagger.io/docs/specification/data-models/data-types/). 2. In [`TableMetadata` builder api](https://github.com/apache/iceberg/blob/7b24f02a6a4645b37f0205ad24af3146df927318/core/src/main/java/org/apache/iceberg/TableMetadata.java#L1179). It makes sense that you don't need to specify `spec_id`, `field_id` before actual committing transaction, since ids should be managed by catalogs. Though we can use some other techniques, for example make them `Option` or use some default value (-1) to simplify it, but I prefer an unbound struct is more clear and type safe. As with `Transform`, I think this is not important due to the api difference of `java` and `rust.` -- 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: issues-unsubscr...@iceberg.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For additional commands, e-mail: issues-h...@iceberg.apache.org
