anoopj commented on code in PR #2922:
URL: https://github.com/apache/iceberg-rust/pull/2922#discussion_r3687390133


##########
crates/iceberg/src/spec/manifest_list/manifest_file.rs:
##########
@@ -195,8 +195,61 @@ impl ManifestFile {
             entry.inherit_data(self);
         }
 
+        self.assign_first_row_ids(&mut entries)?;
+
         Ok(Manifest::new(metadata, entries))
     }
+
+    /// Assigns `first_row_id` to data-file entries that do not already have 
one,
+    /// starting from the manifest-level `first_row_id` and advancing by each
+    /// entry's record count. See the row-lineage inheritance rules in
+    /// 
<https://github.com/apache/iceberg/blob/main/format/spec.md#first-row-id-inheritance>.
+    fn assign_first_row_ids(&self, entries: &mut [ManifestEntry]) -> 
Result<()> {
+        let Some(manifest_first_row_id) = self.first_row_id else {
+            return Ok(());
+        };
+
+        // A `first_row_id` is only valid on data manifests; delete files 
always
+        // have a null `first_row_id`.
+        if self.content != ManifestContentType::Data {
+            return Err(Error::new(
+                ErrorKind::DataInvalid,
+                format!(
+                    "first_row_id is not valid for delete manifests (found 
{manifest_first_row_id} on {})",
+                    self.manifest_path
+                ),
+            ));
+        }
+
+        let mut next_row_id = i64::try_from(manifest_first_row_id).map_err(|_| 
{

Review Comment:
   I recommend leaving it as is. The `u64` type is arguably the a better 
internal model because a first_row_id is non-negative by nature, and the 
Iceberg field is a signed long in the spec only because Avro has no unsigned 
type. The `i64::try_from` is a boundary conversion. 
   
   Also the manifest list writer (`ManifestListWriter` class models it as 
`u64`, so we should probably be consistent. 



-- 
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]

Reply via email to