Skip to content

[SPARK-57644][SQL] TxnTableCatalog should delegate capabilities to underlying catalog#56713

Open
szehon-ho wants to merge 1 commit into
apache:masterfrom
szehon-ho:txn-catalog-capabilities
Open

[SPARK-57644][SQL] TxnTableCatalog should delegate capabilities to underlying catalog#56713
szehon-ho wants to merge 1 commit into
apache:masterfrom
szehon-ho:txn-catalog-capabilities

Conversation

@szehon-ho

@szehon-ho szehon-ho commented Jun 23, 2026

Copy link
Copy Markdown
Member

What changes were proposed in this pull request?

TxnTableCatalog wraps InMemoryRowLevelOperationTableCatalog for transactional row-level operation tests but does not delegate capabilities() to the underlying catalog. This means any capability check through the transactional wrapper returns an empty set.

Fix by delegating capabilities() to the underlying catalog.

Why are the changes needed?

Without this delegation, capability-gated features are invisible through the transactional catalog wrapper. For example, SUPPORT_GENERATED_COLUMN_ON_WRITE (added in SPARK-57644) cannot be checked when the catalog is accessed through TxnTableCatalog, even though the underlying InMemoryRowLevelOperationTableCatalog declares the capability.

Does this PR introduce any user-facing change?

The TxnTableCatalog will expose the capabilities of the underlying Catalog.

How was this patch tested?

Existing tests pass. This is a prerequisite for testing generated column MERGE/UPDATE blocking in SPARK-57644.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Code (claude-opus-4-6)

… to underlying catalog

TxnTableCatalog wraps InMemoryRowLevelOperationTableCatalog for
transactional tests but does not delegate capabilities(). This means
capability-gated features (like SUPPORT_GENERATED_COLUMN_ON_WRITE)
are invisible through the transactional wrapper.

Fix by delegating capabilities() to the underlying catalog.

Co-authored-by: Isaac
@szehon-ho szehon-ho changed the title [SPARK-57644][SQL][TEST] TxnTableCatalog should delegate capabilities to underlying catalog [SPARK-57644][SQL] TxnTableCatalog should delegate capabilities to underlying catalog Jun 23, 2026

@HyukjinKwon HyukjinKwon left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

0 blocking, 0 non-blocking, 0 nits.
Clean, minimal, correct delegation fix.

TxnTableCatalog extends TableCatalog directly, so it inherited the empty capabilities() default; delegating to delegate.capabilities is the right fix and mirrors the existing name delegation in the same class. The return type matches the delegate's inherited signature (no import needed, same package), and capabilities are static catalog properties rather than transaction-scoped state, so plain delegation rather than the staged/commit handling used by alterTable is correct. No findings.

@uros-b uros-b left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

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.

4 participants