@uppy/aws-s3-multipart: add shouldUseMultipart option
#4205
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
Murderlon
added
💬 Discussion
AWS S3
|
If we want to migrate all users of
|
aduh95
force-pushed
the
one-s3-plugin-to-rule-them-all
branch
from
2b5d9a4
to
f7c54db
Compare
aduh95
changed the title
shouldUseMultipart option
Murderlon
reviewed
Apr 28, 2023
| @@ -43,6 +43,7 @@ export interface AwsS3MultipartOptions extends PluginOptions { | |||
| opts: { uploadId: string; key: string; parts: AwsS3Part[]; signal: AbortSignal } | |||
| ) => MaybePromise<{ location?: string }> | |||
| limit?: number | |||
| shouldUseMultipart?: boolean | ((file: UppyFile, fileSize: number) => boolean) | |||
There was a problem hiding this comment.
Why is fileSize the second argument? Doesn't it already live in file?
There was a problem hiding this comment.
It's provided as a convenience.
There was a problem hiding this comment.
I think it's cleaner to just have file. It's not some deep object, it's simply file.size. We can add another argument in the future when people start using it more and need more things or conveniences.
There was a problem hiding this comment.
I agree that if UppyFile always has a .size, then it's unnecessary/confusing/redundant to have a separate argument for it as well
i think it can be considered a breaking change, because i'm changing the signature of uploadPartBytes, which is an option. however I don't see uploadPartBytes documented in our docs, so maybe we can get away with a non major: - onProgress now gets passed number of bytes instead of `ev` - a new `size` argument (previously size was on body)
mifi
reviewed
Apr 28, 2023
(inside multipart)
…sers can use file.size
Merged
github-actions bot
added a commit
that referenced
this pull request
May 2, 2023
| Package | Version | Package | Version | | ---------------------- | ------- | ---------------------- | ------- | | @uppy/aws-s3 | 3.1.1 | @uppy/status-bar | 3.1.2 | | @uppy/aws-s3-multipart | 3.3.0 | @uppy/transloadit | 3.1.4 | | @uppy/locales | 3.2.1 | uppy | 3.9.0 | - @uppy/aws-s3-multipart: allowedMetaFields: null means “include all” (Artur Paikin / #4437) - @uppy/aws-s3-multipart: add `shouldUseMultipart ` option (Antoine du Hamel / #4205) - @uppy/transloadit: Reset `tus` key in the file on error, so retried files are re-uploaded (Artur Paikin / #4421) - meta: commit build file that was modified (Antoine du Hamel) - meta: examples: add CORS settings for DigitalOcean Spaces (Antoine du Hamel / #4428) - @uppy/aws-s3: deprecate `timeout` option (Antoine du Hamel / #4298) - @uppy/aws-s3-multipart: make retries more robust (Antoine du Hamel / #4424) - meta: fix badges on README (Antoine du Hamel / #4419)
| @@ -206,6 +265,9 @@ class HTTPCommunicationQueue { | |||
|
|
|||
| async resumeUploadFile (file, chunks, signal) { | |||
| throwIfAborted(signal) | |||
| if (chunks.length === 1) { | |||
There was a problem hiding this comment.
Should this be checking shouldUseMultipart like we do for uploadFile?
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.
When uploading small files (e.g. ≤100MiB), using multipart can decrease the upload performance as it introduces more overhead for uploading just one part.
This can be solved without too much difficulty by hitting the non-multipart endpoint for files with only one chunk.