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

refactor: Use opendal to replace object_store #978

Merged
merged 21 commits into from
Jan 5, 2025

Conversation

Xuanwo
Copy link
Contributor

@Xuanwo Xuanwo commented Nov 9, 2024

Close #948

This PR will use opendal to replace object_store.

The most significant change is the addition of the GetResponse struct. After this PR, GetResponse will no longer expose any external types; instead, it will provide its own public API that users can rely on.

cc @jondot to take a review, thank you!


There are many things we can consider, such as enabling logging, tracing, and metrics layers to make our storage driver more production-ready. Perhaps we can discuss this later in a separate issue.

@Xuanwo
Copy link
Contributor Author

Xuanwo commented Nov 21, 2024

Some tests are failing. I'm working on it.

@jondot jondot added this to the 0.14.0 milestone Nov 25, 2024
@jondot
Copy link
Contributor

jondot commented Dec 4, 2024

@Xuanwo did you look at the latest CI by a chance?

@Xuanwo
Copy link
Contributor Author

Xuanwo commented Dec 6, 2024

Hi, the only thing left is loco-test. What's the setup of this bucket, is it public acess or we have some env setup in CI?

@jondot
Copy link
Contributor

jondot commented Dec 12, 2024

@Xuanwo we dont have any S3 bucket used for testing, in these specific tests it seems the old implementation would not actually connect to S3 (because the test is testing for failure).
The AWS provider should fail, because we are testing for resilience in the strategies

@Xuanwo
Copy link
Contributor Author

Xuanwo commented Dec 12, 2024

@Xuanwo we dont have any S3 bucket used for testing, in these specific tests it seems the old implementation would not actually connect to S3 (because the test is testing for failure).

The AWS provider should fail, because we are testing for resilience in the strategies

Thank you for the information, I will take an another look.

@Xuanwo
Copy link
Contributor Author

Xuanwo commented Dec 16, 2024

Hi, @jondot sorry for the long waiting. All tests should pass now. Please take another look, thank you!

Copy link
Contributor

@kaplanelad kaplanelad left a comment

Choose a reason for hiding this comment

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

Thanks @Xuanwo! see my question about the panic

let fs = Fs::default().root("/");
Box::new(OpendalAdapter::new(
Operator::new(fs)
.expect("fs service should build with success")
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we handle this without panic?
Would it make more sense to return a Result instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi, I'm willing to return an error if changing the signature is allowed. This PR tries it's best to not change the exposed public API.

Copy link
Contributor

@kaplanelad kaplanelad Dec 18, 2024

Choose a reason for hiding this comment

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

I think it is better than I doing expect.
What do you think? it should't affect the users, right? Only framework changes

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fxied, please review again. Sorry for the late 💌

Box::new(ObjectStoreAdapter::new(Box::new(InMemory::new())))
Box::new(OpendalAdapter::new(
Operator::new(Memory::default())
.expect("memory service must build with success")
Copy link
Contributor

Choose a reason for hiding this comment

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

same question

@kaplanelad
Copy link
Contributor

Thanks @Xuanwo.
Can you avoid braking changes?

@Xuanwo
Copy link
Contributor Author

Xuanwo commented Jan 3, 2025

Thanks @Xuanwo. Can you avoid braking changes?

Hi, this is what I mentioned in #978 (comment).

In fact, the builders for fs and memory are guaranteed to succeed 100%. They only return errors to meet the API requirements of opendal.

@kaplanelad
Copy link
Contributor

got it.

so can you please revert this change? sorry for that

after the ci pass we will merge it

thanks a lot

@Xuanwo
Copy link
Contributor Author

Xuanwo commented Jan 3, 2025

so can you please revert this change? sorry for that

Don't worry, I get it. Let me fix this.

@Xuanwo
Copy link
Contributor Author

Xuanwo commented Jan 3, 2025

Hi, @kaplanelad I have force pushed the changes, please review again. Thank you for the review 💌

@kaplanelad kaplanelad merged commit f05ccb6 into loco-rs:master Jan 5, 2025
9 checks passed
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.

Add OpenDAL as another kind of storage adapter
3 participants