search

janko / uppy-s3_multipart

Provides Ruby endpoints for AWS S3 multipart uploads in Uppy
https://uppy.io/docs/aws-s3/
MIT License
65 stars 21 forks source link

upload to a specific folder in s3 #16

Closed Haofei closed 4 years ago

Haofei commented 4 years ago

thanks for this great library 👍

is it possible to upload object to specific folder in the bucket?

we are managing the files in s3 based on date and file types. currently all the files are uploaded to the root level of the bucket.

janko commented 4 years ago

Yes, specify the :prefix when initializing the Rack app – https://github.com/janko/uppy-s3_multipart#prefix.

timhudson commented 4 years ago

My apologies for reviving this 😝

@janko would you be open to a PR that allows dynamically setting :prefix or key on a per-request basis? Similar to Uppy Companion's providerOptions.s3.getKey(req, filename, metadata) option.

janko commented 4 years ago

You can specify a dynamic per-request :key option for the create_multipart_upload operation, which should provide the necessary flexibility:

options: {
  create_multipart_upload: -> (request) {
    { key: "#{some_dynamic_prefix}/#{SecureRandom.uuid}" }
  }
}
jrochkind commented 4 years ago

I know it's not what you asked, but one "are you sure you want to do this" "A/B problem" response from me:

Shrine typically uses a two-stage storage architecture, with a "cache" storage and a "store" storage. In the typical way to use shrine, uppy-s3_multipart will be uploading to the "cache" storage.

The "cache" storage is meant to be just a temporary holding pen, of resources that after all in this case haven't been vetted in any way by your back-end code, you let the client upload them directly to S3. Everything in cache should, ordinarily fairly quickly, be copied over to 'store' storage instead.

So... are you sure you care about the location of the file in your "cache" storage in such a way that you want to set a per-request/user-specific location for it? I find it fine to let the cache location be totally opaque, but then use normal shrine techniques on the shrine Uploader to set the key/location how I want in "store" storage.

I think there are a lot of things that get simpler when you embrace shrine's two-stage storage model, and the temporary holding pen nature of 'cache'.

timhudson commented 4 years ago

Thanks @janko! I missed that part of the README. I appreciate it.