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

return unsupported for read/stat/delete with version when versioning is not enabled #5145

Closed
wants to merge 1 commit into from

Conversation

meteorgan
Copy link
Contributor

Which issue does this PR close?

None

Rationale for this change

As discussed in: #5132 (comment)
We should return Unsupported error for every operation with version when versioning is not enabled

What changes are included in this PR?

Are there any user-facing changes?

@@ -958,6 +958,13 @@ impl Access for S3Backend {
}

async fn stat(&self, path: &str, args: OpStat) -> Result<RpStat> {
if args.version().is_some() && !self.core.enable_versioning {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, this PR suggests that we consider introducing a layer to handle unsupported behaviors. Not all users and use cases are concerned about whether services support versioning; they might simply want to write code consistently and return it as is if not supported.


We have similar code here:

fn new_unsupported_error(&self, op: impl Into<&'static str>) -> Error {
let scheme = self.meta.scheme();
let op = op.into();
Error::new(
ErrorKind::Unsupported,
format!("service {scheme} doesn't support operation {op}"),
)
.with_operation(op)
}

I think we can create a new layer called CapabilityCheckLayer. By default, opendal will not perform any capability checks. Users can enable CapabilityCheckLayer to ensure the features they use are supported and behave as expected.

CapabilityCheckLayer may have different modes:

  • Default: just bypass all checks, like the opendal default behavior.
  • Correctness: only check capability that affected correctness, for example, write with if none match, read with version.
  • All: check all capabilities.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. Let me think about how to implement them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shall we remove the check in list before implementing this CapabilityCheckLayer ?

@Xuanwo Xuanwo mentioned this pull request Oct 21, 2024
@meteorgan meteorgan closed this Nov 8, 2024
@meteorgan meteorgan deleted the versioning_api branch December 3, 2024 05:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants