Implement capability API rename#7710
Draft
Xuanwo wants to merge 1 commit into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Which issue does this PR close?
N/A. Implements RFC #7700.
Rationale for this change
RFC #7700 simplifies OpenDAL's capability model by making
Capabilitythe single user-facing type andOperatorInfo::capability()the recommended availability check. The previousnative_capability()andfull_capability()naming made users choose between backend-declared and effective capabilities even though most user code only needs the effective operator capability.What changes are included in this PR?
This PR adds
OperatorInfo::capability()and renames raw internals toservice_capability()/set_service_capability()andcapability()/update_capability(). The old native/full APIs remain as deprecated compatibility aliases.It also updates services, layers, behavior tests, the object_store integration, binding shims, binding docs, and upgrade notes to use the new effective capability terminology.
Are there any user-facing changes?
Yes. Users should migrate from
OperatorInfo::full_capability()toOperatorInfo::capability().full_capability()andnative_capability()remain available as deprecated compatibility APIs.Bindings add matching capability accessors where applicable while keeping existing full/native APIs for compatibility.
AI Usage Statement
AI assistance was used to implement and check this change.