adityaksolves commented on PR #18502:
URL: https://github.com/apache/iceberg/pull/18502#issuecomment-6665309749
Thanks @RussellSpitzer, that’s a fair question. You’re right that a v2+
table can legitimately hold v1 manifests, e.g. ones carried over from an
upgrade, and those scan fine.
The failure is specific to adding a v1 manifest through
RewriteManifests.addManifest. Repro (formatVersion 2, 3 and 4): build a v1
manifest with EXISTING entries,
deleteManifest(original).addManifest(v1Manifest).commit(), then
table.newScan().planFiles(). The commit succeeds, but planning throws:
java.lang.NullPointerException: Cannot invoke "java.lang.Long.longValue()"
because the return value of
"org.apache.iceberg.ManifestEntry.dataSequenceNumber()" is null
at org.apache.iceberg.DeleteFileIndex.forEntry(DeleteFileIndex.java:151)
at
org.apache.iceberg.ManifestGroup.lambda$createFileScanTasks$14(ManifestGroup.java:400)
Before the commit the manifest is unassigned (sequenceNumber=-1,
snapshotId=null); after the commit it gets sequenceNumber=2, snapshotId=2 in
the manifest list. A v1 manifest has no sequence number column, so its entries
rely on inheritance, and InheritableMetadataFactory only inherits the
manifest’s sequence number when it is 0 or the entry is ADDED. Here the entries
are EXISTING and the manifest sequence number is 2, so neither holds and
dataSequenceNumber stays null. A v1 manifest carried over from an upgrade keeps
sequence number 0, which is why that case works.
So I agree v1 manifests on v2+ tables are fine in general; the problem is
only this add path. I went with rejecting because it fails fast, but I’m happy
to switch to rewriting the manifest with sequence number 0 for its entries, as
iceberg-cpp does (apache/iceberg-cpp#774), if you’d prefer that. Which would
you prefer?
--
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]
