This is an automated email from the ASF dual-hosted git repository.
kevinjqliu 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 ad116d604d Docs: Fix several nit issues in docs (#15419)
ad116d604d is described below
commit ad116d604dbeb2a4b4115ecba639d22c476ddcee
Author: Anshul Baliga <[email protected]>
AuthorDate: Mon Feb 23 23:58:33 2026 +0530
Docs: Fix several nit issues in docs (#15419)
---
docs/docs/aws.md | 4 ++--
docs/docs/flink-configuration.md | 2 +-
docs/docs/flink-maintenance.md | 2 +-
docs/docs/spark-procedures.md | 2 +-
format/spec.md | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/docs/docs/aws.md b/docs/docs/aws.md
index 9c979b9da8..1fe8674012 100644
--- a/docs/docs/aws.md
+++ b/docs/docs/aws.md
@@ -270,9 +270,9 @@ Read [this AWS
documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserG
With all the available options, we offer the following guidelines when
choosing the right catalog to use for your application:
1. if your organization has an existing Glue metastore or plans to use the AWS
analytics ecosystem including Glue, [Athena](https://aws.amazon.com/athena),
[EMR](https://aws.amazon.com/emr), [Redshift](https://aws.amazon.com/redshift)
and [LakeFormation](https://aws.amazon.com/lake-formation), Glue catalog
provides the easiest integration.
-2. if your application requires frequent updates to table or high read and
write throughput (e.g. streaming write), Glue and DynamoDB catalog provides the
best performance through optimistic locking.
+2. if your application requires frequent updates to table or high read and
write throughput (e.g. streaming write), Glue and DynamoDB catalogs provide the
best performance through optimistic locking.
3. if you would like to enforce access control for tables in a catalog, Glue
tables can be managed as an [IAM
resource](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsglue.html),
whereas DynamoDB catalog tables can only be managed through [item-level
permission](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/specifying-conditions.html)
which is much more complicated.
-4. if you would like to query tables based on table property information
without the need to scan the entire catalog, DynamoDB catalog allows you to
build secondary indexes for any arbitrary property field and provide efficient
query performance.
+4. if you would like to query tables based on table property information
without the need to scan the entire catalog, DynamoDB catalog allows you to
build secondary indexes for any arbitrary property field and provides efficient
query performance.
5. if you would like to have the benefit of DynamoDB catalog while also
connect to Glue, you can enable [DynamoDB stream with Lambda
trigger](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.Lambda.Tutorial.html)
to asynchronously update your Glue metastore with table information in the
DynamoDB catalog.
6. if your organization already maintains an existing relational database in
RDS or uses [serverless Aurora](https://aws.amazon.com/rds/aurora/serverless/)
to manage tables, the JDBC catalog provides the easiest integration.
diff --git a/docs/docs/flink-configuration.md b/docs/docs/flink-configuration.md
index 41d3df0745..f30b422888 100644
--- a/docs/docs/flink-configuration.md
+++ b/docs/docs/flink-configuration.md
@@ -123,7 +123,7 @@ env.getConfig()
| include-column-stats | connector.iceberg.include-column-stats
| N/A | false | Create a
new scan from this that loads the column stats with each data file. Column
stats include: value count, null value count, lower bounds, and upper bounds.
[...]
| max-planning-snapshot-count |
connector.iceberg.max-planning-snapshot-count | N/A
| Integer.MAX_VALUE | Max number of snapshots limited per split
enumeration. Applicable only to streaming read.
[...]
| limit | connector.iceberg.limit
| N/A | -1 | Limited
output number of rows.
[...]
-| max-allowed-planning-failures |
connector.iceberg.max-allowed-planning-failures | N/A
| 3 | Max allowed consecutive failures for scan
planning before failing the job. Set to -1 for never failing the job for scan
planing failure.
[...]
+| max-allowed-planning-failures |
connector.iceberg.max-allowed-planning-failures | N/A
| 3 | Max allowed consecutive failures for scan
planning before failing the job. Set to -1 for never failing the job for scan
planning failure.
[...]
| watermark-column | connector.iceberg.watermark-column
| N/A | null |
Specifies the watermark column to use for watermark generation. If this option
is present, the `splitAssignerFactory` will be overridden with
`OrderedSplitAssignerFactory`.
[...]
| watermark-column-time-unit | connector.iceberg.watermark-column-time-unit
| N/A | TimeUnit.MICROSECONDS |
Specifies the watermark time unit to use for watermark generation. The possible
values are DAYS, HOURS, MINUTES, SECONDS, MILLISECONDS, MICROSECONDS,
NANOSECONDS.
[...]
diff --git a/docs/docs/flink-maintenance.md b/docs/docs/flink-maintenance.md
index 37fb9a7a84..1afa35034f 100644
--- a/docs/docs/flink-maintenance.md
+++ b/docs/docs/flink-maintenance.md
@@ -224,7 +224,7 @@ env.execute("Table Maintenance Job");
| Method | Description
| Default Value | Type |
|------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------|--------------------|
-| `location(string)` | The location to start the
recursive listing the candidate files for removal.
| Table's location | String |
+| `location(string)` | The location to start the
recursive listing of the candidate files for removal.
| Table's location | String |
| `usePrefixListing(boolean)` | When true, use prefix-based file
listing via the SupportsPrefixOperations interface. The Table FileIO
implementation must support SupportsPrefixOperations when this flag is
enabled.(Note: Setting it to False will use a recursive method to obtain file
information. If the underlying storage is object storage, it will repeatedly
call the API to get the path.) | False | boolean |
| `prefixMismatchMode(PrefixMismatchMode)` | Action behavior when location
prefixes (schemes/authorities) mismatch: <ul><li>ERROR - throw an exception.
</li><li>IGNORE - no action.</li><li>DELETE - delete files.</li></ul>
| ERROR | PrefixMismatchMode |
| `equalSchemes(Map<String, String>)` | Mapping of file system schemes to
be considered equal. Key is a comma-separated list of schemes and value is a
scheme
| "s3n"=>"s3","s3a"=>"s3" | Map<String,String> |
diff --git a/docs/docs/spark-procedures.md b/docs/docs/spark-procedures.md
index c040f49ef8..4544f6533d 100644
--- a/docs/docs/spark-procedures.md
+++ b/docs/docs/spark-procedures.md
@@ -401,7 +401,7 @@ Iceberg can compact data files in parallel using Spark with
the `rewriteDataFile
| `max-concurrent-file-group-rewrites` | 5 | Maximum number of file groups to
be simultaneously rewritten |
| `partial-progress.enabled` | false | Enable committing groups of files prior
to the entire rewrite completing |
| `partial-progress.max-commits` | 10 | Maximum amount of commits that this
rewrite is allowed to produce if partial progress is enabled |
-| `partial-progress.max-failed-commits` | value of
`partital-progress.max-commits` | Maximum amount of failed commits allowed
before job failure, if partial progress is enabled |
+| `partial-progress.max-failed-commits` | value of
`partial-progress.max-commits` | Maximum amount of failed commits allowed
before job failure, if partial progress is enabled |
| `use-starting-sequence-number` | true | Use the sequence number of the
snapshot at compaction start time instead of that of the newly produced
snapshot |
| `rewrite-job-order` | none | Force the rewrite job order based on the value.
<ul><li>If rewrite-job-order=bytes-asc, then rewrite the smallest job groups
first.</li><li>If rewrite-job-order=bytes-desc, then rewrite the largest job
groups first.</li><li>If rewrite-job-order=files-asc, then rewrite the job
groups with the least files first.</li><li>If rewrite-job-order=files-desc,
then rewrite the job groups with the most files first.</li><li>If
rewrite-job-order=none, then rewrite job g [...]
| `target-file-size-bytes` | 536870912 (512 MB, default value of
`write.target-file-size-bytes` from [table
properties](configuration.md#write-properties)) | Target output file size |
diff --git a/format/spec.md b/format/spec.md
index 43348d856c..0d3c79762c 100644
--- a/format/spec.md
+++ b/format/spec.md
@@ -1485,7 +1485,7 @@ Older versions of the reference implementation can read
tables with transforms u
### Sort Orders
-Sort orders are serialized as a list of JSON object, each of which contains
the following fields:
+Sort orders are serialized as a list of JSON objects, each of which contains
the following fields:
|Field|JSON representation|Example|
|--- |--- |--- |
