This is an automated email from the ASF dual-hosted git repository.
etudenhoefner pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/iceberg.git
The following commit(s) were added to refs/heads/main by this push:
new daa24f9c3a Docs: Fix rendering lists (#11546)
daa24f9c3a is described below
commit daa24f9c3a56e18d188097deb2dd79cc991c9a78
Author: Manu Zhang <[email protected]>
AuthorDate: Thu Nov 14 18:48:48 2024 +0800
Docs: Fix rendering lists (#11546)
---
format/puffin-spec.md | 1 +
format/spec.md | 2 ++
format/view-spec.md | 2 ++
3 files changed, 5 insertions(+)
diff --git a/format/puffin-spec.md b/format/puffin-spec.md
index 0148db72e2..62e8ae0853 100644
--- a/format/puffin-spec.md
+++ b/format/puffin-spec.md
@@ -145,6 +145,7 @@ sub-position) are tested for inclusion in the bitmap. If a
bitmap is not found
for the key, then it is not set.
The serialized blob contains:
+
* Combined length of the vector and magic bytes stored as 4 bytes, big-endian
* A 4-byte magic sequence, `D1 D3 39 64`
* The vector, serialized as described below
diff --git a/format/spec.md b/format/spec.md
index c9a5f71510..631008c5da 100644
--- a/format/spec.md
+++ b/format/spec.md
@@ -262,6 +262,7 @@ Iceberg's Avro manifest format does not store the type of
lower and upper bounds
| `decimal(P, S)` | _any_ | `decimal(P', S)`; `P' <= P` |
Type promotion is not allowed for a field that is referenced by `source-id` or
`source-ids` of a partition field if the partition transform would produce a
different value after promoting the type. For example, `bucket[N]` produces
different hash values for `34` and `"34"` (2017239379 != -427558391) but the
same value for `34` and `34L`; when an `int` field is the source for a bucket
partition field, it may be promoted to `long` but not to `string`. This may
happen for the following type [...]
+
* `date` to `timestamp` or `timestamp_ns`
Any struct, including a top-level schema, can evolve through deleting fields,
adding new fields, renaming existing fields, reordering existing fields, or
promoting a primitive using the valid type promotions. Adding a new field
assigns a new ID for that field and for any nested fields. Renaming an existing
field must change the name, but not the field ID. Deleting a field removes it
from the current schema. Field deletion cannot be rolled back unless the field
was nullable or if the curr [...]
@@ -1001,6 +1002,7 @@ Notes:
This section details how to encode row-level deletes in Iceberg delete files.
Row-level deletes are added by v2 and are not supported in v1. Deletion vectors
are added in v3 and are not supported in v2 or earlier. Position delete files
must not be added to v3 tables, but existing position delete files are valid.
There are three types of row-level deletes:
+
* Deletion vectors (DVs) identify deleted rows within a single referenced data
file by position in a bitmap
* Position delete files identify deleted rows by file location and row
position (**deprecated**)
* Equality delete files identify deleted rows by the value of one or more
columns
diff --git a/format/view-spec.md b/format/view-spec.md
index ff44d9d3bb..011781d9e4 100644
--- a/format/view-spec.md
+++ b/format/view-spec.md
@@ -65,6 +65,7 @@ The view version metadata file has the following fields:
| _optional_ | `properties` | A string to string map of view
properties [2] |
Notes:
+
1. The number of versions to retain is controlled by the table property:
`version.history.num-entries`.
2. Properties are used for metadata such as `comment` and for settings that
affect view maintenance. This is not intended to be used for arbitrary metadata.
@@ -102,6 +103,7 @@ A view version can have more than one representation. All
representations for a
View versions are immutable. Once a version is created, it cannot be changed.
This means that representations for a version cannot be changed. If a view
definition changes (or new representations are to be added), a new version must
be created.
Each representation is an object with at least one common field, `type`, that
is one of the following:
+
* `sql`: a SQL SELECT statement that defines the view
Representations further define metadata for each type.
