rdblue commented on code in PR #17932:
URL: https://github.com/apache/iceberg/pull/17932#discussion_r3938099334
##########
api/src/main/java/org/apache/iceberg/ManifestFile.java:
##########
@@ -210,6 +210,11 @@ default Long firstRowId() {
return null;
}
+ /** Returns the manifest deletion vector, or null if absent. */
+ default ByteBuffer manifestDeletionVector() {
Review Comment:
Originally, I thought that we could come back and update the return type
here, but I was wrong because this is a public API interface. So I think rather
than using `ByteBuffer` as a placeholder we should introduce a type to return.
That means we need to decide on a name and whether we want a generic
interface for all bitmaps/DVs or if we want one for the manifest/embedded use
case. We already have `DeletionVector` that tracks DV metadata, and
`PositionDeleteIndex` for DVs that we've loaded into memory.
I don't think we want to reuse `PositionDeleteIndex` because it's mutable
and represents a bitmap that could have positions that are in the range of
longs. That's also in core so moving it to API to use it here would be a bigger
change.
Instead, I think we should introduce `EmbeddedBitmap` or `ManifestBitmap`
(suggested by @anoopj) and use `int` for positions. Using a name based on
"bitmap" makes it distinct from `DeletionVector`. Here's a minimal read-only
interface that I think we can use:
```java
package org.apache.iceberg;
import java.nio.ByteBuffer;
/** Interface for small bitmaps that are serialized in metadata files. */
public interface EmbeddedBitmap {
/** Number of bits set in this bitmap. */
int cardinality();
/** Return whether the bit at {@code position} is set. */
boolean isSet(int position);
/** Return the serialized bitmap as a {@link ByteBuffer}. */
ByteBuffer buffer();
}
```
We can also make that smaller if we are concerned about releasing any of
those methods. All we really need to decide is the name, but I think we are
definitely targeting the `int` position range so this makes sense to me.
--
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]
