Unification Extended-key format in Java FilerClient #5490
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
But with this, a user would not be able to set the S3 specific headers with Java FilerClient. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What problem are we solving?
When using Filer Http to process files, setting Extended-key must carry the "Seaweed-" prefix, and the prefix will be persisted to the file.
When using Java FilerClient to process files, setting Extended-key does not force the "Seaweed-" prefix.
Therefore, the format of Extended-key for the files processed in the two ways is not uniform.
Therefore, when dealing with Entry in Client, it is necessary to distinguish between the two formats of Extended-key, but it is obviously unrealistic to require users to pay extra attention to the two formats of Extended-key when using FilerClient, and it is necessary to unify the format of Extended-key in Client.
How are we solving the problem?
Refer to the implementation of S3, add a certain prefix to the user-defined metadata, and erase the prefix when querying.
Add a utility class to add and remove "Seaweed-" prefixes for Extended-key.
The "Seaweed-" prefix is automatically appended when the Entry is submitted, and the "Seaweed-" prefix is automatically removed when the Entry is pulled.
Achieve the unification of Extended-key format, that is, the Extended-key of Entry will carry the "Seaweed-" prefix, but the user will not display the "Seaweed-" prefix when obtaining Entry (such as lookUpEntry).
Therefore, when using Client, users are completely unaware of the "Seaweed-" prefix, but the format of Extended is unified.
How is the PR tested?
add Unit test in SeaweedFilerTest
Checks