stevenzwu commented on code in PR #16425:
URL: https://github.com/apache/iceberg/pull/16425#discussion_r4517777207
##########
format/spec.md:
##########
@@ -1801,6 +1805,51 @@ If a delete column in an equality delete file is later
dropped from the table, i
Manifests hold the same statistics for delete files and data files. For delete
files, the metrics describe the values that were deleted.
+### Column Files
+
+Starting in v4, a data file or v4 leaf manifest may store fields in column
files listed in [`column_files`](#column-file-fields). A column file can use
any supported Iceberg file format and must have rows that align with the file
it modifies.
+
+A column file stores the fields listed in its `field_ids`. A listed struct
includes all fields nested in it. In this section, a struct _contains_ a field
if the field is nested in the struct at any depth.
+
+When a column file is added, each ID in its `field_ids` must identify a field
in the schema of the file it modifies, or a row lineage field required by
[Writing Column Files](#writing-column-files). The schema of a data file is the
table schema. The schema of a leaf manifest is the tracked file schema. Fields
nested in a list or map must not be listed in `field_ids`.
+
+#### Writing Column Files
+
+A column file stores the value of each of its listed fields for every row of
the file it modifies. Values that did not change are still included, and values
for deleted rows should be null.
+
+The added column files must list each field that the update changes, or a
struct that contains that field. If an update changes whether a struct is null,
the update changes that struct.
+
+When column files are added to a data file or a leaf manifest, the writer must
produce a MODIFIED entry and a REPLACED entry as described in [Updating
Tracking Metadata](#updating-tracking-metadata). The MODIFIED entry and the
REPLACED entry may be written to different manifests.
+
+The `tracking` fields of the MODIFIED entry are set as described in [Updating
Tracking Metadata](#updating-tracking-metadata) and [Sequence Number
Inheritance](#sequence-number-inheritance), and `tracking.snapshot_id` must be
the previous entry's (inherited) snapshot ID. For a leaf manifest,
`tracking.sequence_number` must not change. The fields of the MODIFIED entry
outside `tracking` must match the previous entry, except for the following:
+
+- `partition`:
+ - For a data file, an added column file may list a field that is, or
contains, a source field of the data file's partition spec only if every row
that is not deleted has the same partition values after the update. `partition`
must be set to those values.
+- `sort_order_id`:
+ - If an added column file lists a field that is, or contains, a field in
the sort order, `sort_order_id` must be null.
+- `content_stats`:
+ - Stats for a field listed in an added column file, and for its nested
fields, must be computed from that column file, or omitted.
+ - For a leaf manifest, stats that summarize a listed field must be
recomputed or omitted.
+- `tight_stats`:
+ - `tight_stats` may be true only if `content_stats` are tight for the rows
that are live after the update (see [Stats Tightness](#stats-tightness)).
Review Comment:
"may be true only if" mixes a permission with a condition, and "for the rows
that are live" repeats the Stats Tightness definition. Stated as a conditional
requirement:
```suggestion
- If `tight_stats` is true, `content_stats` must be tight for the live
rows after the update (see [Stats Tightness](#stats-tightness)).
```
##########
format/spec.md:
##########
@@ -1801,6 +1804,44 @@ If a delete column in an equality delete file is later
dropped from the table, i
Manifests hold the same statistics for delete files and data files. For delete
files, the metrics describe the values that were deleted.
+### Column Files
+
+Starting in v4, a data file or v4 leaf manifest may store fields in column
files listed in [`column_files`](#column-file-fields). A column file can use
any supported Iceberg file format and must have rows that align with the file
it modifies.
+
+A column file stores the fields listed in its `field_ids`, each as a whole,
including all of its nested fields. Each ID must identify a field in the schema
of the file it modifies, which is the table schema for a data file and the
tracked file schema for a leaf manifest, or a row lineage field required by
[Writing Column Files](#writing-column-files). Fields nested within a list or
map must not be listed in `field_ids`.
+
+#### Writing Column Files
+
+The rules below apply to column files of data files. Rules for writing column
files of leaf manifests are not defined here.
Review Comment:
just `file` seems a little vague to me. I found `base file` reflects our
column overlay approach more accurately. there is a special base file that
don't have `field_ids`
--
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]
