gaborkaszab commented on code in PR #16025:
URL: https://github.com/apache/iceberg/pull/16025#discussion_r3376322192


##########
format/spec.md:
##########
@@ -685,21 +701,100 @@ The `manifest_entry` struct consists of the following 
fields:
     |            | _optional_ | **`4  file_sequence_number`** | `long`         
                                           | File sequence number indicating 
when the file was added. Inherited when null and status is 1 (added). |
     | _required_ | _required_ | **`2  data_file`**            | `data_file` 
`struct` (see below)                          | File path, partition tuple, 
metrics, ... |
 
-The manifest entry fields are used to keep track of the snapshot in which 
files were added or logically deleted. The `data_file` struct, defined below, 
is nested inside the manifest entry so that it can be easily passed to job 
planning without the manifest entry fields.
+    The manifest entry fields are used to keep track of the snapshot in which 
files were added or logically deleted. The `data_file` struct, defined below, 
is nested inside the manifest entry so that it can be easily passed to job 
planning without the manifest entry fields.
 
-When a file is added to the dataset, its manifest entry should store the 
snapshot ID in which the file was added and set status to 1 (added).
+    When a file is added to the dataset, its manifest entry should store the 
snapshot ID in which the file was added and set status to 1 (added).
 
-When a file is replaced or deleted from the dataset, its manifest entry fields 
store the snapshot ID in which the file was deleted and status 2 (deleted). The 
file may be deleted from the file system when the snapshot in which it was 
deleted is garbage collected, assuming that older snapshots have also been 
garbage collected [1].
+    When a file is replaced or deleted from the dataset, its manifest entry 
fields store the snapshot ID in which the file was deleted and status 2 
(deleted). The file may be deleted from the file system when the snapshot in 
which it was deleted is garbage collected, assuming that older snapshots have 
also been garbage collected [1].
 
-Iceberg v2 adds data and file sequence numbers to the entry and makes the 
snapshot ID optional. Values for these fields are inherited from manifest 
metadata when `null`. That is, if the field is `null` for an entry, then the 
entry must inherit its value from the manifest file's metadata, stored in the 
manifest list.
-The `sequence_number` field represents the data sequence number and must never 
change after a file is added to the dataset. The data sequence number 
represents a relative age of the file content and should be used for planning 
which delete files apply to a data file.
-The `file_sequence_number` field represents the sequence number of the 
snapshot that added the file and must also remain unchanged upon assigning at 
commit. The file sequence number can't be used for pruning delete files as the 
data within the file may have an older data sequence number.
-The data and file sequence numbers are inherited only if the entry status is 1 
(added). If the entry status is 0 (existing) or 2 (deleted), the entry must 
include both sequence numbers explicitly.
+    Iceberg v2 adds data and file sequence numbers to the entry and makes the 
snapshot ID optional. Values for these fields are inherited from manifest 
metadata when `null`. That is, if the field is `null` for an entry, then the 
entry must inherit its value from the manifest file's metadata, stored in the 
manifest list.
+    The `sequence_number` field represents the data sequence number and must 
never change after a file is added to the dataset. The data sequence number 
represents a relative age of the file content and should be used for planning 
which delete files apply to a data file.
+    The `file_sequence_number` field represents the sequence number of the 
snapshot that added the file and must also remain unchanged upon assigning at 
commit. The file sequence number can't be used for pruning delete files as the 
data within the file may have an older data sequence number.
+    The data and file sequence numbers are inherited only if the entry status 
is 1 (added). If the entry status is 0 (existing) or 2 (deleted), the entry 
must include both sequence numbers explicitly.
 
-Notes:
+    Notes:
+
+    1. Technically, data files can be deleted when the last snapshot that 
contains the file as "live" data is garbage collected. But this is harder to 
detect and requires finding the diff of multiple snapshots. It is easier to 
track what files are deleted in a snapshot and delete them when that snapshot 
expires.  It is not recommended to add a deleted file back to a table. Adding a 
deleted file can lead to edge cases where incremental deletes can break table 
snapshots.
+    2. Manifest list files are required in v2, so that the `sequence_number` 
and `snapshot_id` to inherit are always available.
 
-1. Technically, data files can be deleted when the last snapshot that contains 
the file as “live” data is garbage collected. But this is harder to detect and 
requires finding the diff of multiple snapshots. It is easier to track what 
files are deleted in a snapshot and delete them when that snapshot expires.  It 
is not recommended to add a deleted file back to a table. Adding a deleted file 
can lead to edge cases where incremental deletes can break table snapshots.
-2. Manifest list files are required in v2, so that the `sequence_number` and 
`snapshot_id` to inherit are always available.
+=== "v4"
+    **Content Entries**
+
+    | Field id | Name | Type | Write | Read | Description |
+    |----------|------|------|-------|------|-------------|
+    | 134 | **`content_type`** | `int` (0: DATA, 2: EQUALITY DELETES, 3: 
DATA_MANIFEST, 4: DELETE_MANIFEST) | *required* | *required* | Type of content 
stored in the entry. Content types 3 and 4 are only valid in root manifests. |
+    | 157 | **`writer_format_version`** | `int` (0: PRE-V4, 1: V4) | 
*required* | *required* | Writer format version. V4 writers must produce 
`writer_format_version` 1. |
+    | 100 | **`location`** | `string` | *required* | *required* | Location of 
the file or manifest. |
+    | 101 | **`file_format`** | `string` | *required* | *required* | String 
file format name: `avro`, `orc`, `parquet`, or `puffin` |
+    | 147 | **`tracking`** | `tracking` struct | *required* | *required* | 
Groups status, snapshot, and sequence number. See tracking struct below. |
+    | 141 | **`spec_id`** | `int` | *optional* | *optional* | ID of the 
partition spec used to write this manifest or data file. |
+    | 140 | **`sort_order_id`** | `int` | *optional* | *optional* | ID 
representing sort order for this file. |
+    | 103 | **`record_count`** | `long` | *required* | *required* | Number of 
records in this file. |
+    | 104 | **`file_size_in_bytes`** | `long` | *required* | *required* | 
Total file size in bytes. |
+    | 146 | **`content_stats`** | `content_stats` struct | *optional* | 
*optional* | Column stats. See [Column Stats 
Improvements](#column-stats-improvements). |
+    | 150 | **`manifest_info`** | `manifest_info` struct | *optional* | 
*optional* | See manifest_info struct below. |
+    | 131 | **`key_metadata`** | `binary` | *optional* | *optional* | 
Implementation-specific key metadata for encryption. |
+    | 132 | **`split_offsets`** | `list<133: long>` | *optional* | *optional* 
| Split offsets for the data file. Must be sorted ascending. |
+    | 135 | **`equality_ids`** | `list<136: int>` | *optional* | *optional* | 
Field ids for row equality in equality delete files. |
+    | 148 | **`deletion_vector`** | `deletion_vector` struct | *optional* | 
*optional* | Row-level deletion vector for a data file. |
+    | 158 | **`column_files`** | `list<column_file>` | *optional* | *optional* 
| Column update files associated with this entry. |
+
+    Value 1 (POSITION_DELETES) is not used in v4. Writers must not produce 
`content_type` 1.
+
+    V4 leaf data manifests must only contain entries with `content_type` 0 
(DATA); V4 leaf delete manifests must only contain entries with `content_type` 
2 (EQUALITY DELETES). A root manifest may reference V1-V3 manifests; V1-V3 leaf 
manifest references must have `writer_format_version` set to 0.
+
+    The following constraints apply based on `content_type`:
+
+    - `manifest_info` must be set when `content_type` is 3 or 4; must be null 
otherwise.

Review Comment:
   Also ,should be null if `content_type` is 0 or 2, right?



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