-
Notifications
You must be signed in to change notification settings - Fork 3.5k
API, Core: Introduce a generic abstraction to replace ManifestListFile #17545
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -71,6 +71,11 @@ default InputFile newInputFile(ManifestFile manifest) { | |
| return newInputFile(manifest.path(), manifest.length()); | ||
| } | ||
|
|
||
| /** | ||
| * @deprecated since 1.12.0. Will be removed in 2.0.0; use {@link #newInputFile(String, String)} | ||
| * instead. | ||
| */ | ||
| @Deprecated | ||
| default InputFile newInputFile(ManifestListFile manifestList) { | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I dropped |
||
| Preconditions.checkArgument( | ||
| manifestList.encryptionKeyID() == null, | ||
|
|
@@ -80,6 +85,13 @@ default InputFile newInputFile(ManifestListFile manifestList) { | |
| return newInputFile(manifestList.location()); | ||
| } | ||
|
|
||
| default InputFile newInputFile(String location, String keyId) { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. While this made sense for "manifest List" i'm not sure it makes sense for a generic path. The caller of this method has control over whether or not they are passing through a String. If they choose to pass through a string shouldn't we be using it? Do we have other examples of API's where an argument can be ignored if it is null and fall back to another polymorphism?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the general case what I have in mind is that we don't want the callers to branch on whether keyId is null or not. It's a cleaner implementation to call This way the caller code is clean enough, no need to branch on keyId being null, we can fallback to the unencrypted case inside About other such APIs, I'm not sure about other APIs, but the |
||
| Preconditions.checkArgument( | ||
| keyId == null, "Cannot decrypt file: %s (use EncryptingFileIO)", location); | ||
| // cannot pass length because it is not tracked outside of key metadata | ||
| return newInputFile(location); | ||
| } | ||
|
|
||
| /** Get a {@link OutputFile} instance to write bytes to the file at the given path. */ | ||
| OutputFile newOutputFile(String path); | ||
|
|
||
|
|
||
This file was deleted.
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 probably would change this to require that keyId is nonNull.
I don't think we want folks calling this method if they don't expect to be using a key
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.
Precondition keyId.notNull
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 think such a precondition would break the contract of
EncryptionFileIO. If I'm not mistaken,EncryptingFileIOtheoretically can be created even if the table is not encrypted, and other functions here also seem to branch onkey_metadatabeing null or not, where null defaults to the non-encrypting case. I think for consistency we should follow that pattern with thekeyIdvariation ofnewFileIOfunctions.WDYT @RussellSpitzer ?
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'm not sure I follow. In this PR we now provide 2 APIs
new inputFile(String location)
and
new InputFile(String location, String keyID)
Usually I would expect the first to call the second. But here we have the second call the first.
The question is what is the point of the first API if I have the second one and can pass String keyID) as null. My assumption would be that if I pass through a keyId I am attempting to have that used by the fileIO. If I have passed through "null" I'm probably not doing something right because I should have called "new inputFile(location)".
We also should consider the integration of this API with the "Length" passthrough
Let me jump down to default definition to add some more comments
Uh oh!
There was an error while loading. Please reload this page.
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 think overall we are still stuck a bit too much mimicking the logic that was here before for ManifestLists without thinking about how we would add this API by first principals.
We are essentially adding a new API that a FileIO user can call if they have key metadata. We know they also will have a path and may have a length. So it probably makes sense to build this up similar to the other methods in FileIO.
Right now we have
So we probably also need
Then the question would be if you are in EncryptingFileIO should the implementation fail if keyMetadata is null? Because the library user has expressly used a method which implies keyMetadata is important, so is it OK to just fall back to non-ecryption behavior? I don't feel comfortable with that but others may have a different opinion.
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 think having a length param could make sense as you described above to be consistent with other function and to have a length available in the "fallback to unencrypted read" case.
My understanding might not be that strong here, but I think for manifests list files we are in a weird situation because we don't directly keep the length of the physical encrypted file. We do keep the location and keyId on the snapshot, and in turn we can get the keyMetadata based on the keyId. When it comes to reading we assume that the length is integrated into keyMetadata. So for manifest list files I don't think there is a straightforward way to use the proposed
newInputFile(path, length, keyMetadata or keyId).Just a general comment, that with the proposed new function, we could technically wipe out all the variations of
newInputFile(DataFile),newInputFile(DeleteFile),newInputFile(ManifestFile)because all they need is a path, a length and keyMetadata. Unfortunately, we keep no length for manifest list files as described above.Should we proposed keeping the length in
Snapshotfor the new V4 root manifest since we are actively working on it and then we can avoid relying on length being embedded into keyMetadata and could use length as a param fornewInputFile? cc @amogh-jahagirdar @stevenzwuOn the question of should we fail if keyMetadata is null or fallback to the unencrypted path, I think the latter is cleaner on the caller side. See my example on the other comment.