moomindani commented on code in PR #2802:
URL: https://github.com/apache/iceberg-rust/pull/2802#discussion_r4473253203
##########
crates/iceberg/src/spec/partition.rs:
##########
@@ -34,10 +34,18 @@ pub(crate) const DEFAULT_PARTITION_SPEC_ID: i32 = 0;
/// Partition fields capture the transform from table data to partition values.
#[derive(Debug, Serialize, Deserialize, PartialEq, Eq, Clone, TypedBuilder)]
-#[serde(rename_all = "kebab-case")]
+#[serde(
+ try_from = "_serde_partition_field::PartitionFieldSerde",
+ into = "_serde_partition_field::PartitionFieldSerde"
+)]
pub struct PartitionField {
/// A source column id from the table’s schema
pub source_id: i32,
+ /// Source column ids when the transform takes multiple arguments (v3
multi-argument
+ /// transforms). `None` for single-argument transforms, where `source_id`
is used instead.
+ /// When set, `source_id` holds the first id so that existing consumers
keep working.
+ #[builder(default)]
+ pub source_ids: Option<Vec<i32>>,
Review Comment:
Thanks for raising this. I looked at splitting by spec version, but for
partition fields the choice between `source-id` and `source-ids` is driven by
the number of arguments, not the format version: a single-argument field is
still written with `source-id` in v3. A per-version struct would need that same
check inside each variant, so I kept one `_serde` struct per field type, which
keeps the rule in one place and matches `UnboundPartitionField` from #3267.
The one version-dependent rule is that v1/v2 metadata must not contain
multi-argument fields. A partition field does not know which format version it
belongs to, so that check fits in `TableMetadata`. It is outside this refactor,
so I left it out; I am happy to add it here if you would like it in this PR.
The same reasoning applies to `SortField`.
--
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]