-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Core: add key_metadata to ManifestFile spec #2675
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| .add("deleted_data_files_count", deletedFilesCount) | ||
| .add("deleted_rows_count", deletedRowsCount) | ||
| .add("partitions", partitions) | ||
| .add("key_metadata", keyMetadata == null ? "null" : "(redacted)") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would actually be more against using this approach to support redact, for 2 reasons:
- this is only for
toString. If you really want to see the details of the key metadata you can read through the manifest table, and that should show the information fully if you can decrypt an encrypted manifest list. I think that provides better access control. ChangingtoStringfeels to me like opening a backdoor. - if we can encrypt a manifest, we should be able to support redact configuration natively through encryption manager as a part of data masking. When we can do that, you don't need a forked version to use a custom static method for this purpose.
RussellSpitzer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, do we have anyone else we are waiting on to get this merged? @aokolnychyi ?
flyrain
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, thanks for the PR.
|
@RussellSpitzer we are not waiting for anyone to merge, but I thought for any format v2 change @rdblue should take a look and approve. If it's not necessary we will merge to unblock other subsequent changes. |
| } | ||
|
|
||
| @Override | ||
| public ByteBuffer keyMetadata() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this used in tests? We could just allow this to use the default implementation, unless we added tests that exercise it.
@flyrain @rdblue @ggershinsky
first step based on draft #2520, simply add
keyMetadatato the interface and implementations, pass innullfor any caller.