twuebi commented on PR #1665: URL: https://github.com/apache/iceberg-go/pull/1665#issuecomment-5315743981
@laskoviymishka, dug a bit in iceberg-rust, they do all client-side things unbound, `TableCreation.partition_spec` is `Option<UnboundPartitionSpec>` (`crates/iceberg/src/catalog/mod.rs:330`), so is the wire struct `CreateTableRequest.partition_spec` (`crates/catalog/rest/src/types.rs:258`), and the REST client forwards one straight into the other (`crates/catalog/rest/src/catalog.rs:755`). The reasoning carries over: a spec passed to `CreateTable` references the caller's schema, whose IDs get reassigned, so it plays the same placeholder role as a decoded Spark request and both directions share one JSON shape, so one type should serve both. If we do it here, we need to re-type `catalog.WithPartitionSpec` which is the shared `CreateTableOpt` surface for REST, Glue, etc. And would also give `UnboundPartitionSpec` a construction path. Rust has `into_unbound()` (`partition.rs:111`), `From<PartitionSpec>` and a builder, we only got `UnmarshalJSON`. That'd be a breaking change to a public API and should probably be discussed in separate and not get folded into this decode-side bug-fix. For now, I've left a note in `catalog/rest/rest.go:225` pointing at the unbound types & #1664. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
