Feature Request / Improvement
write.metadata.previous-versions-max is currently floored to 1:
|
int maxSize = |
|
Math.max( |
|
1, |
|
PropertyUtil.propertyAsInt( |
|
properties, |
|
TableProperties.METADATA_PREVIOUS_VERSIONS_MAX, |
|
TableProperties.METADATA_PREVIOUS_VERSIONS_MAX_DEFAULT)); |
so a table always retains at least one previous metadata file in the metadata-log.
I was a bit confused by this, because I don't see a concrete reason to disallow empty metadata logs; I'd therefore like to know what folks think about permitting a value of 0 instead to enable this.
With write.metadata.delete-after-commit.enabled=true, this would then delete the superseded metadata file on every commit.
(My use case for this is from a REST catalog standpoint where an empty metadata log would allow metadata JSON to be "self-contained" and only reference its current snapshots, instead of indirectly reference snapshots in prior metadata files too)
Query engine
None
Willingness to contribute
Feature Request / Improvement
write.metadata.previous-versions-maxis currently floored to 1:iceberg/core/src/main/java/org/apache/iceberg/TableMetadata.java
Lines 1801 to 1807 in 70b9033
so a table always retains at least one previous metadata file in the
metadata-log.I was a bit confused by this, because I don't see a concrete reason to disallow empty metadata logs; I'd therefore like to know what folks think about permitting a value of 0 instead to enable this.
With
write.metadata.delete-after-commit.enabled=true, this would then delete the superseded metadata file on every commit.(My use case for this is from a REST catalog standpoint where an empty metadata log would allow metadata JSON to be "self-contained" and only reference its current snapshots, instead of indirectly reference snapshots in prior metadata files too)
Query engine
None
Willingness to contribute