Interface AppendFiles
- All Superinterfaces:
PendingUpdate<Snapshot>
,SnapshotUpdate<AppendFiles>
This API accumulates file additions, produces a new Snapshot
of the table, and commits
that snapshot as the current.
When committing, these changes will be applied to the latest table snapshot. Commit conflicts will be resolved by applying the changes to the new latest snapshot and reattempting the commit.
-
Method Summary
Modifier and TypeMethodDescriptionappendFile
(DataFile file) Append aDataFile
to the table.appendManifest
(ManifestFile file) Append aManifestFile
to the table.Methods inherited from interface org.apache.iceberg.PendingUpdate
apply, commit, updateEvent
Methods inherited from interface org.apache.iceberg.SnapshotUpdate
deleteWith, scanManifestsWith, set, stageOnly, toBranch
-
Method Details
-
appendFile
Append aDataFile
to the table.- Parameters:
file
- a data file- Returns:
- this for method chaining
-
appendManifest
Append aManifestFile
to the table.The manifest must contain only appended files. All files in the manifest will be appended to the table in the snapshot created by this update.
The manifest will be used directly if snapshot ID inheritance is enabled (all tables with the format version > 1 or if the inheritance is enabled explicitly via table properties). Otherwise, the manifest will be rewritten to assign all entries this update's snapshot ID.
If the manifest is rewritten, it is always the responsibility of the caller to manage the lifecycle of the original manifest. If the manifest is used directly, it should never be deleted manually if the commit succeeds as it will become part of the table metadata and will be cleaned upon expiry. If the manifest gets merged with others while preparing a new snapshot, it will be deleted automatically if this operation is successful. If the commit fails, the manifest will never be deleted, and it is up to the caller whether to delete or reuse it.
- Parameters:
file
- a manifest file- Returns:
- this for method chaining
-