moomindani opened a new issue, #2789: URL: https://github.com/apache/iceberg-rust/issues/2789
### Apache Iceberg Rust version 0.6.0 (latest version) ### Describe the bug The V3 spec requires: "All v3 readers are required to read tables with unknown transforms, ignoring them." `FromStr for Transform` returns an error for any unrecognized transform name — only the literal string `"unknown"` maps to `Transform::Unknown` — so loading a table whose partition spec or sort order uses a transform iceberg-rust does not know fails entirely. Names sharing a prefix with known transforms (e.g. `bucketv2[4]`) also fail. Additionally, `Transform::Unknown` does not retain the original name and displays as `"unknown"`, so rewriting metadata through the builder would corrupt the transform name. For comparison, Java's `Transforms.fromString` falls back to `UnknownTransform`, which preserves the original string, and PyIceberg implemented the same behavior in apache/iceberg-python#3630. ### To Reproduce ```rust use iceberg::spec::Transform; let _ = "zorder".parse::<Transform>(); // Err(DataInvalid), expected Transform::Unknown let _ = "bucketv2[4]".parse::<Transform>(); // Err(DataInvalid), expected Transform::Unknown ``` Loading table metadata containing such a transform fails the same way. ### Expected behavior Unrecognized transform names parse as an unknown transform that preserves the original name, tables containing them load and scan (with no partition pruning on those fields), and the name round-trips through serialization. A fix likely means `Transform::Unknown(String)` (a breaking enum change) plus a parse fallback — noting the interaction with #2474, which is currently tightening the same parser to reject malformed parameters of known transforms. ### Willingness to contribute I would be willing to contribute a fix for this bug with guidance from the Iceberg community -- 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]
