Skip to content

[refine](column) separate mutable subcolumn mutation from read-only traversal#65087

Open
Mryange wants to merge 1 commit into
apache:masterfrom
Mryange:refine-column-for_each_subcolumn
Open

[refine](column) separate mutable subcolumn mutation from read-only traversal#65087
Mryange wants to merge 1 commit into
apache:masterfrom
Mryange:refine-column-for_each_subcolumn

Conversation

@Mryange

@Mryange Mryange commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

What problem does this PR solve?

Column wrappers used for_each_subcolumn for both read-only traversal and mutable subcolumn detachment during COW mutation. These two operations have different contracts: read-only paths only need const IColumn&, while COW mutation needs to replace child pointer slots.

Root cause: the old mutable callback accepted IColumn::WrappedPtr&, but several composite columns store strongly typed child wrappers, such as nullable null maps and array/map offsets. That forced ad-hoc move-out and cast-back bridges, and made read-only callers use mutable traversal or const_cast.

This change keeps for_each_subcolumn as a const read-only traversal API and adds mutate_subcolumns() for the COW mutation path. Composite columns now detach children through mutate_subcolumn helpers, and read-only recursive checks use the const traversal directly. A dedicated BE unit test file verifies that mutating exclusive subcolumns does not introduce extra clones, while shared subcolumns are still detached.

Release note

None

Check List (For Author)

  • Test

    • Regression test
    • Unit Test
    • Manual test (add detailed scripts or steps below)
    • No need to test or manual test. Explain why:
      • This is a refactor/code format and no logic has been changed.
      • Previous test can cover this change.
      • No code files have been changed.
      • Other reason
  • Behavior changed:

    • No.
    • Yes.
  • Does this need documentation?

    • No.
    • Yes.

Check List (For Reviewer who merge this PR)

  • Confirm the release note
  • Confirm test cases
  • Confirm document
  • Add branch pick label

@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

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