Skip to content

[Kernel] Enable variant and shredding RW support - #5222

Merged
scottsand-db merged 4 commits into
delta-io:masterfrom
amogh-jahagirdar:enable-variant-feature-support
Sep 23, 2025
Merged

scottsand-db merged 4 commits into
delta-io:masterfrom
amogh-jahagirdar:enable-variant-feature-support

Conversation

@amogh-jahagirdar

@amogh-jahagirdar amogh-jahagirdar commented Sep 17, 2025 •

Copy link
Copy Markdown
Collaborator

Which Delta project/connector is this regarding?

  • Spark
  • Standalone
  • Flink
  • Kernel
  • Other (fill in here)

Description

This change enables variant and shredding RW support. We still preserve the preview for variant though probably at some point we should remove supporting that in Kernel. Another change that is made is that when shredding is enabled, variant is automatically enabled by making it a required dependent feature.

Furthermore, since this change is about enabling metadata write support in Kernel we block physical writes when there's a variant in Transaction#transformLogicalData similar to how kernel blocks writes on table for column mapping but allows metadata writes.

How was this patch tested?

Added unit tests

Does this PR introduce any user-facing changes?

@amogh-jahagirdar
amogh-jahagirdar force-pushed the enable-variant-feature-support branch from 97e2bfb to bf15c65 Compare September 17, 2025 16:39
public boolean hasKernelWriteSupport(Metadata metadata) {
return false; // TODO: yet to be implemented in Kernel
public Set<TableFeature> requiredFeatures() {
return new HashSet<>(Arrays.asList(TableFeatures.VARIANT_RW_FEATURE));

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

one issue (not sure if it is):
If the table already has the varaintType-preview and you enable shredding through metadata config. With this requiredFeatures, it will have both the variantType and variantType-preview in the table protocol.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

I don't think this is an issue because the feature sets are the same (so there's no logical source of truth issue) but I do wonder if we should (in a follow on) introduce an abstraction for features to have some ability to disable existing features. e.g. any time a "graduated" feature is enabled, it goes and removes the "preview" feature if it's set on the table. This keeps the protocol cleaner

@allisonport-db allisonport-db Sep 17, 2025 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Edit: ignore this comment
I think for type widening we did something specific for graduating features. Can we do the same thing here?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think this abstraction makes sense -- if you have a table with variantType-preview, and you somehow (either through implicit updates, or explicitly) enable variantType, can we remove variantType-preview?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

@richardc-db any concern if both variant-preview and variant are enabled on the table?

@richardc-db richardc-db Sep 18, 2025 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

i don't think theres a concern for now if a small subset of tables have both (ideally most tables are on variantType and not variantType-preview). Agree it would be cleaner to somehow remove the -preview feature, but AFAIK we don't currently have that capability.

public boolean hasKernelWriteSupport(Metadata metadata) {
return false; // TODO: yet to be implemented in Kernel
public Set<TableFeature> requiredFeatures() {
return new HashSet<>(Arrays.asList(TableFeatures.VARIANT_RW_FEATURE));

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think this abstraction makes sense -- if you have a table with variantType-preview, and you somehow (either through implicit updates, or explicitly) enable variantType, can we remove variantType-preview?

@allisonport-db allisonport-db left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

LGTM

@scottsand-db
scottsand-db merged commit ad1d55f into delta-io:master Sep 23, 2025
27 checks passed
@felipepessoto

Copy link
Copy Markdown
Contributor

@amogh-jahagirdar, @allisonport-db. The release notes claim variant read and write is supported by Kernel, but in the description here I noticed it is limited to metadata write.

What do we mean by "metadata write"?

huashi-st pushed a commit to huashi-st/delta that referenced this pull request Apr 24, 2026
<!--
Thanks for sending a pull request!  Here are some tips for you:
1. If this is your first time, please read our contributor guidelines:
https://github.com/delta-io/delta/blob/master/CONTRIBUTING.md
2. If the PR is unfinished, add '[WIP]' in your PR title, e.g., '[WIP]
Your PR title ...'.
  3. Be sure to keep the PR description updated to reflect all changes.
  4. Please write your PR title to summarize what this PR proposes.
5. If possible, provide a concise example to reproduce the issue for a
faster review.
6. If applicable, include the corresponding issue number in the PR title
and link it in the body.
-->

#### Which Delta project/connector is this regarding?
<!--
Please add the component selected below to the beginning of the pull
request title
For example: [Spark] Title of my pull request
-->

- [ ] Spark
- [ ] Standalone
- [ ] Flink
- [x] Kernel
- [ ] Other (fill in here)

## Description

<!--
- Describe what this PR changes.
- Describe why we need the change.
 
If this PR resolves an issue be sure to include "Resolves #XXX" to
correctly link and close the issue upon merge.
-->

This change enables variant and shredding RW support. We still preserve
the preview for variant though probably at some point we should remove
supporting that in Kernel. Another change that is made is that when
shredding is enabled, variant is automatically enabled by making it a
required dependent feature.

Furthermore, since this change is about enabling metadata write support
in Kernel we block physical writes when there's a variant in
Transaction#transformLogicalData similar to how kernel blocks writes on
table for column mapping but allows metadata writes.

## How was this patch tested?

<!--
If tests were added, say they were added here. Please make sure to test
the changes thoroughly including negative and positive cases if
possible.
If the changes were tested in any way other than unit tests, please
clarify how you tested step by step (ideally copy and paste-able, so
that other reviewers can test and check, and descendants can verify in
the future).
If the changes were not tested, please explain why.
-->

Added unit tests

## Does this PR introduce _any_ user-facing changes?

<!--
If yes, please clarify the previous behavior and the change this PR
proposes - provide the console output, description and/or an example to
show the behavior difference if possible.
If possible, please also clarify if this is a user-facing change
compared to the released Delta Lake versions or within the unreleased
branches such as master.
If no, write 'No'.
-->
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.

6 participants