Skip to content
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

Provide case-insensitive storage options in backend #999

Closed
fvaleye opened this issue Dec 6, 2022 · 1 comment · Fixed by #1052
Closed

Provide case-insensitive storage options in backend #999

fvaleye opened this issue Dec 6, 2022 · 1 comment · Fixed by #1052
Labels
enhancement New feature or request

Comments

@fvaleye
Copy link
Collaborator

fvaleye commented Dec 6, 2022

Description

The S3 storage_options is case-sensitive for the moment (example: created with from_map, which could lead to not retrieve storage_options provided with lowercases parameters (example: from the Python binding using a simple storage_options dictionary).

Use Case

Allow case-insensitive storage options to provide more flexibility to the user when passing the storage_options via parameters.

@fvaleye fvaleye added the enhancement New feature or request label Dec 6, 2022
@roeap
Copy link
Collaborator

roeap commented Dec 6, 2022

We updated the azure and gcp options to be case-insensitive, and I meant to get around to updating the s3 options as well. We should however review the options all together, since some of these no longer do anything since we switches to object_store. specifically, object store does not expose as many options for the http client.. however the lock client still uses rusoto, which may in fact honor these options, so it needs a bit of a deeper look what we want to expose.

wjones127 added a commit that referenced this issue Jan 11, 2023
# Description
Recently we moved some of our storage configuration via a property bag
upstream to the object_store crate. This allows us to simplify our
configuration handling here and make S3 configuration consistent with
azure and gcp.

I think as a follow up it would be great to migrate dynamodb_lock to
using the official SDKs as well, and then see what we still need form
the s3 storage options.

# Related Issue(s)

closes #999

# Documentation

<!---
Share links to useful documentation
--->

Co-authored-by: Will Jones <[email protected]>
chitralverma pushed a commit to chitralverma/delta-rs that referenced this issue Mar 17, 2023
# Description
Recently we moved some of our storage configuration via a property bag
upstream to the object_store crate. This allows us to simplify our
configuration handling here and make S3 configuration consistent with
azure and gcp.

I think as a follow up it would be great to migrate dynamodb_lock to
using the official SDKs as well, and then see what we still need form
the s3 storage options.

# Related Issue(s)

closes delta-io#999

# Documentation

<!---
Share links to useful documentation
--->

Co-authored-by: Will Jones <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants