-
Notifications
You must be signed in to change notification settings - Fork 858
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
Add more options for FileAsyncResponseTransformer #1222
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1222 +/- ##
============================================
+ Coverage 59.02% 59.27% +0.24%
- Complexity 4632 4651 +19
============================================
Files 747 747
Lines 23183 23197 +14
Branches 1737 1738 +1
============================================
+ Hits 13684 13749 +65
+ Misses 8805 8743 -62
- Partials 694 705 +11
Continue to review full report at Codecov.
|
Missed the default delete-on-error behavior. I'll need to fix that. |
479b363
to
899da25
Compare
Add the following things to control the behavior of the transformer: - position parameter to specify where in the file to write the stream - isNewFile parameter to specify whether this is a new file - deleteOnFailure to specify whether the file should be deleted on failure
899da25
to
9749ff7
Compare
* @return AsyncResponseTransformer instance. | ||
*/ | ||
static <ResponseT> AsyncResponseTransformer<ResponseT, ResponseT> toFile(Path path, | ||
long position, |
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 wonder if we should use a request wrapper for this. Something like toFile(Path path, FileOption option)
? My concern is that we might need to add other parameters in the future.
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 in that case case a Builder
might be a better option, something like
AsyncResponseTransformer.toFileTransformerBuilder()
.position(...)
.deleteOnFailure(...)
.build();
We have one for FileAsyncRequestBody
Line 103 in a751924
public interface Builder extends SdkBuilder<Builder, FileAsyncRequestBody> { |
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.
Like the idea of builder but I'm not sure if we want to put toFileTransformerBuilder
api to AsyncResponseTransformer
.
What would toFile
look like? toFile(FileAsyncResponseTransformer.Builder builder)
?
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.
We can probably just keep toFile(Path)
as-is, since it's behavior is probably what most customers want. This extra stuff is for less common/more specialized cases I would think (such as use in the transfer manager).
Closing this for now. |
Description
Add the following things to control the behavior of the transformer:
Motivation and Context
File opening flexibility.
Testing
Added new tests.
Screenshots (if appropriate)
Types of changes
Checklist
mvn install
succeedsLicense