refactor(proto): migrate FilterExec serde - #23708
Merged
Merged
Conversation
|
Thank you for opening this pull request! Reviewer note: cargo-semver-checks reported the current version number is not SemVer-compatible with the changes in this pull request (compared against the base branch). Details |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #23708 +/- ##
==========================================
- Coverage 80.71% 80.70% -0.01%
==========================================
Files 1089 1089
Lines 368280 368293 +13
Branches 368280 368293 +13
==========================================
- Hits 297250 297237 -13
- Misses 53314 53341 +27
+ Partials 17716 17715 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This was referenced Jul 20, 2026
adriangb
requested changes
Jul 20, 2026
Comment on lines
+2960
to
+2963
| #[deprecated( | ||
| since = "55.0.0", | ||
| note = "unused by DataFusion; `FilterExec` serializes itself via `ExecutionPlan::try_to_proto`" | ||
| )] |
Contributor
There was a problem hiding this comment.
Can we have the deprecated method delegate to the new one to avoid code duplication and drift?
The centralized protobuf dispatcher couples each execution plan to datafusion-proto. Adding plan serialization therefore requires changes outside the plan implementation. Move FilterExec encoding and decoding behind its ExecutionPlan hooks. Preserve the existing wire format and retain the old helper methods as deprecated compatibility APIs. CLOSES apache#23499 Signed-off-by: Jiawei Zhao <Phoenix500526@163.com>
FilterExec serde moved to per-plan hooks, but the deprecated PhysicalPlanNodeExt helpers retained separate implementations. Keeping the wire-format logic in both paths allows the compatibility API to drift from normal dispatch. Build the existing encode and decode adapter contexts in the deprecated helpers and forward to FilterExec's canonical hooks, preserving the old API without duplicating serialization logic. Refs apache#23499 Signed-off-by: Jiawei Zhao <Phoenix500526@163.com>
Phoenix500526
force-pushed
the
issue/23499
branch
from
July 21, 2026 05:16
3d8e61c to
7172823
Compare
adriangb
enabled auto-merge
July 21, 2026 05:35
athlcode
pushed a commit
to athlcode/datafusion
that referenced
this pull request
Jul 23, 2026
…w hooks (apache#23731) ## Which issue does this PR close? - Part of apache#23494. ## Rationale for this change apache#23495 landed the deprecated `ProjectionExec` compatibility shims (`try_from_projection_exec` / `try_into_projection_physical_plan`) with their original bodies fully duplicated in `datafusion-proto`, even though the same wire-format logic now lives in `ProjectionExec::try_to_proto` / `try_from_proto` (the apache#22419 hook pattern). This PR makes those deprecated shims **delegate** to the new hooks so the wire format is single-sourced in `datafusion-physical-plan` rather than duplicated. This matches the `FilterExec` delegate style in apache#23708. No wire-format change. ## What changes are included in this PR? - Replace the body of `try_from_projection_exec` with a thin shim that builds an `ExecutionPlanEncodeCtx` from the `codec` + `proto_converter` (via `ConverterPlanEncoder`) and delegates to `ProjectionExec::try_to_proto`. - Replace the body of `try_into_projection_physical_plan` with a thin shim that builds an `ExecutionPlanDecodeCtx` (via `ConverterPlanDecoder`) and delegates to `ProjectionExec::try_from_proto`; the now-unused `projection` param is renamed to `_projection`. - Drop the now-unused `ProjectionExpr` import. The `#[deprecated(...)]` attributes and signatures are otherwise unchanged, and the live dispatch arms and the `ProjectionExec` hook impls are untouched. ## Are these changes tested? Yes — the existing `roundtrip_physical_plan` projection/filter roundtrip tests exercise this path and pass (`roundtrip_projection_source`, `roundtrip_filter_with_fetch`, `roundtrip_filter_with_not_and_in_list`, and the full 203-test `roundtrip` suite). `cargo clippy -p datafusion-proto --all-features -- -D warnings` is clean. ## Are there any user-facing changes? No. The methods remain `#[deprecated]` with identical signatures and wire format; only their internals change. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01U9qX6kekbJGpmTSxvrU8e5 --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
kosiew
pushed a commit
to kosiew/datafusion
that referenced
this pull request
Aug 12, 2026
## Which issue does this PR close? <!-- We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax. For example `Closes apache#123` indicates that this PR will close issue apache#123. --> - Closes apache#23499. ## Rationale for this change <!-- Why are you proposing this change? If this is already explained clearly in the issue then this section is not needed. Explaining clearly why changes are proposed helps reviewers understand your changes and offer better suggestions for fixes. --> The centralized protobuf dispatcher couples each execution plan to datafusion-proto. Adding plan serialization therefore requires changes outside the plan implementation. Move FilterExec encoding and decoding behind its ExecutionPlan hooks. Preserve the existing wire format and retain the old helper methods as deprecated compatibility APIs. ## What changes are included in this PR? <!-- There is no need to duplicate the description in the issue here but it is sometimes worth providing a summary of the individual changes in this PR. --> ## Are these changes tested? <!-- We typically require tests for all PRs in order to: 1. Prevent the code from being accidentally broken by subsequent changes 2. Serve as another way to document the expected behavior of the code If tests are not included in your PR, please explain why (for example, are they covered by existing tests)? --> Yes ## Are there any user-facing changes? <!-- If there are user-facing changes then we may require documentation to be updated before approving the PR. --> <!-- If there are any breaking changes to public APIs, please add the `api change` label. --> --------- Signed-off-by: Jiawei Zhao <Phoenix500526@163.com>
kosiew
pushed a commit
to kosiew/datafusion
that referenced
this pull request
Aug 12, 2026
…w hooks (apache#23731) ## Which issue does this PR close? - Part of apache#23494. ## Rationale for this change apache#23495 landed the deprecated `ProjectionExec` compatibility shims (`try_from_projection_exec` / `try_into_projection_physical_plan`) with their original bodies fully duplicated in `datafusion-proto`, even though the same wire-format logic now lives in `ProjectionExec::try_to_proto` / `try_from_proto` (the apache#22419 hook pattern). This PR makes those deprecated shims **delegate** to the new hooks so the wire format is single-sourced in `datafusion-physical-plan` rather than duplicated. This matches the `FilterExec` delegate style in apache#23708. No wire-format change. ## What changes are included in this PR? - Replace the body of `try_from_projection_exec` with a thin shim that builds an `ExecutionPlanEncodeCtx` from the `codec` + `proto_converter` (via `ConverterPlanEncoder`) and delegates to `ProjectionExec::try_to_proto`. - Replace the body of `try_into_projection_physical_plan` with a thin shim that builds an `ExecutionPlanDecodeCtx` (via `ConverterPlanDecoder`) and delegates to `ProjectionExec::try_from_proto`; the now-unused `projection` param is renamed to `_projection`. - Drop the now-unused `ProjectionExpr` import. The `#[deprecated(...)]` attributes and signatures are otherwise unchanged, and the live dispatch arms and the `ProjectionExec` hook impls are untouched. ## Are these changes tested? Yes — the existing `roundtrip_physical_plan` projection/filter roundtrip tests exercise this path and pass (`roundtrip_projection_source`, `roundtrip_filter_with_fetch`, `roundtrip_filter_with_not_and_in_list`, and the full 203-test `roundtrip` suite). `cargo clippy -p datafusion-proto --all-features -- -D warnings` is clean. ## Are there any user-facing changes? No. The methods remain `#[deprecated]` with identical signatures and wire format; only their internals change. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01U9qX6kekbJGpmTSxvrU8e5 --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
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?
Rationale for this change
The centralized protobuf dispatcher couples each execution plan to datafusion-proto. Adding plan serialization therefore requires changes outside the plan implementation.
Move FilterExec encoding and decoding behind its ExecutionPlan hooks. Preserve the existing wire format and retain the old helper methods as deprecated compatibility APIs.
What changes are included in this PR?
Are these changes tested?
Yes
Are there any user-facing changes?