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

chore: bump opendal to v0.45.1 for connector/icelake #15920

Merged
merged 1 commit into from
Mar 26, 2024

Conversation

xiangjinwu
Copy link
Contributor

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Supplement to #15744.

Note that icelake specifies >=0.40, causing dependabot to automatically bump it to 0.45. But our connector requires 0.44, leading to all dependabot PRs blocked.

Checklist

  • I have written necessary rustdoc comments
  • I have added necessary unit tests and integration tests
  • I have added test labels as necessary. See details.
  • I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
  • My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
  • All checks passed in ./risedev check (or alias, ./risedev c)
  • My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)
  • My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

  • My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

@xiangjinwu xiangjinwu requested a review from a team as a code owner March 26, 2024 10:12
@xiangjinwu xiangjinwu requested review from BugenZhao and wcy-fdu March 26, 2024 10:12
@xxchan xxchan added this pull request to the merge queue Mar 26, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Mar 26, 2024
@xxchan xxchan added this pull request to the merge queue Mar 26, 2024
Merged via the queue into main with commit f292e7b Mar 26, 2024
29 of 30 checks passed
@xxchan xxchan deleted the bump-opendal-connector-icelake branch March 26, 2024 15:14
@@ -126,6 +128,7 @@ impl<Src: OpendalSource> OpendalReader<Src> {
let reader = op
.reader_with(&object_name)
.range(split.offset as u64..)
.into_future() // Unlike `rustc`, `try_stream` seems require manual `into_future`.
Copy link
Member

Choose a reason for hiding this comment

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

What does rustc refer to? 👀

Copy link
Contributor Author

@xiangjinwu xiangjinwu Mar 27, 2024

Choose a reason for hiding this comment

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

It refers to the normal .await desugaring performed by rustc, in contrast to how the proc macro try_stream transforms the .await syntax.

That is, given f: impl IntoFuture, we can write f.await directly but need f.into_future().await if try_stream is involved.

Copy link
Member

Choose a reason for hiding this comment

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

This is interesting. Heard about IntoFuture a long time ago and finally meet one in practice.

Copy link
Contributor Author

@xiangjinwu xiangjinwu Mar 27, 2024

Choose a reason for hiding this comment

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

opendal::Operator::reader_with returns:

  • (v0.44.2) FutureReader which implements Future
  • (v0.45.1) FutureRead which implements IntoFuture

When implementing futures manually there will often be a choice between implementing Future or IntoFuture for a type. Implementing Future is a good choice in most cases. But implementing IntoFuture is most useful when implementing “async builder” types, which allow their values to be modified multiple times before being .awaited.

The .range call is modifying its value before being .awaited

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants