Skip to content

[SPARK-52729][SQL][FOLLOWUP] Rename MetadataOnlyTable to MetadataTable and RelationCatalog to TableViewCatalog#55587

Closed
gengliangwang wants to merge 2 commits into
apache:masterfrom
gengliangwang:SPARK-52729-followup-rename-metadata-table
Closed

[SPARK-52729][SQL][FOLLOWUP] Rename MetadataOnlyTable to MetadataTable and RelationCatalog to TableViewCatalog#55587
gengliangwang wants to merge 2 commits into
apache:masterfrom
gengliangwang:SPARK-52729-followup-rename-metadata-table

Conversation

@gengliangwang
Copy link
Copy Markdown
Member

What changes were proposed in this pull request?

Renames for the v2 catalog API introduced in #51419 (SPARK-52729):

  • MetadataOnlyTableMetadataTable
  • RelationCatalogTableViewCatalog
  • RelationCatalog.loadRelationTableViewCatalog.loadTableOrView

Plus mechanical follow-on renames:

  • Catalogs.validateRelationCatalogvalidateTableViewCatalog
  • TestingRelationCatalog (test fixture) → TestingTableViewCatalog
  • DataSourceV2MetadataOnlyTableSuiteDataSourceV2MetadataTableSuite
  • DataSourceV2MetadataOnlyViewSuiteDataSourceV2MetadataViewSuite

Out of scope (intentionally untouched):

  • CatalogV2Util.loadRelation(catalog, ident) — pre-existing TableNamedRelation helper, unrelated to the renamed method.
  • RelationResolution.loadRelation(V2TableReference) — unrelated private method on the analyzer.
  • OptimizeMetadataOnlyQuery and friends — separate "metadata-only query" optimizer concept.

Why are the changes needed?

  • MetadataOnlyTable reads more naturally as MetadataTable — the type is a Table backed by a TableInfo (or ViewInfo), mirroring the underlying DTO. The "Only" qualifier adds length without conveying additional meaning.
  • RelationCatalog collides with Spark's heavily-overloaded "Relation" terminology (BaseRelation, LogicalRelation, UnresolvedRelation — all data-source v1 concepts). TableViewCatalog is explicit about the kinds it covers and pairs symmetrically with TableCatalog / ViewCatalog.
  • loadTableOrView describes the method's contract directly ("returns a Table for a table, or a MetadataTable wrapping a ViewInfo for a view") instead of leaning on the overloaded "Relation" term.

Does this PR introduce any user-facing change?

For connector developers: yes — the renamed types and method are part of the new DS v2 catalog API. The original names ship in 4.2.0 (unreleased at time of this PR), so the rename lands before any release exposes them. No SQL-level or runtime behavior change.

How was this patch tested?

Existing test suites renamed and re-run:

  • DataSourceV2MetadataTableSuite — 4 tests, all pass.
  • DataSourceV2MetadataViewSuite — 56 tests, all pass.

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

Generated-by: Claude (Anthropic)

…ewCatalog, loadRelation -> loadTableOrView

- MetadataTable drops the "Only" qualifier; reads naturally as the Table backed by a
  TableInfo (and ViewInfo via subclass).
- TableViewCatalog explicitly names what the interface covers and avoids overloading
  Spark's "Relation" terminology (BaseRelation, LogicalRelation, etc.).
- TableViewCatalog.loadTableOrView is the single-RPC perf entry point; the new name
  matches the contract on the interface ("returns a Table or a view"). The unrelated
  helpers CatalogV2Util.loadRelation and the private RelationResolution.loadRelation
  (V2TableReference -> LogicalPlan) keep their names.

Test fixture TestingRelationCatalog -> TestingTableViewCatalog. Suites
DataSourceV2MetadataOnlyTableSuite/DataSourceV2MetadataOnlyViewSuite -> drop "Only"
to mirror the class.
@gengliangwang gengliangwang requested a review from cloud-fan April 28, 2026 20:02
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.

1 participant