LuciferYang opened a new pull request, #10282: URL: https://github.com/apache/paimon/pull/10282
### Purpose `deletion-vectors.bitmap64` is not an immutable option, so it can be flipped with `ALTER TABLE ... SET` on a table that already has deletion vectors. After a flip, a freshly created deletion vector (in the new format) has to merge with a stored one (in the old format), but `Bitmap64DeletionVector.merge` and `BitmapDeletionVector.merge` reject a different class with `Only instance with the same class type can be merged.`, crashing the delete. Both flip directions are affected, and the crash occurs on both the unaware-append and bucketed-append merge paths. This adds `DeletionVector.mergeVectors(fresh, stored)`, which promotes the bitmap32 side to bitmap64 (via the existing `fromBitmapDeletionVector`) whenever either side is bitmap64 and then merges at the wider format, and routes both `AppendDeleteFileMaintainer.notifyNewDeletionVector` and `BucketedDvMaintainer.mergeNewDeletion` through it. A bitmap64 result reads back correctly regardless of the current option value, because deletion vectors are dispatched by magic number on read and bitmap32/bitmap64 vectors already coexist within one index file. This closes #10281. ### Tests - `AppendDeletionFileMaintainerTest` pins both flip directions on the unaware-append path (stored bitmap32 + fresh bitmap64, and the reverse). - `BucketedDvMaintainerTest` pins both flip directions on the bucketed-append path. Each fails on the pre-fix code with the class-type `RuntimeException`. ### API and Format No. The on-disk deletion-vector format is unchanged; the fix only merges the two existing formats in memory. ### Documentation No. -- 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]
