cloud-fan opened a new pull request, #56606:
URL: https://github.com/apache/spark/pull/56606
### What changes were proposed in this pull request?
This is a follow-up of #52729 (which introduced `ViewInfo extends
TableInfo`).
Previously `ViewInfo` extended `TableInfo` purely so that a `MetadataTable`
(which wraps a `TableInfo`) could also carry a `ViewInfo`, enabling the
single-RPC `TableViewCatalog#loadTableOrView` perf path. The side effect was
that `ViewInfo` inherited table-only state that is meaningless for views:
`partitions()` / `constraints()` accessors (returning empty arrays) and the
`withPartitions` / `withConstraints` / `withProvider` / `withLocation` builder
setters (callable on a view builder but semantically wrong).
This PR makes `TableInfo` and `ViewInfo` sibling subclasses of a new common
base instead:
```
RelationInfo (abstract) // columns, schema(), properties()
+ BaseBuilder<B> //
withColumns/withSchema/withProperties
//
withComment/withCollation/withOwner/withTableType
|-- TableInfo extends RelationInfo // adds partitions, constraints
| + Builder // adds
withPartitions/withConstraints/withProvider/withLocation
+-- ViewInfo extends RelationInfo // adds queryText, sqlConfigs,
schemaMode, ... viewDependencies
+ Builder // adds the view setters only
```
`MetadataTable` now wraps a `RelationInfo`, and `getTableInfo()` is renamed
to `getRelationInfo()`. Its `partitioning()` / `constraints()` return empty for
a non-`TableInfo` payload. The single-RPC perf path is preserved unchanged;
consumers discriminate via `getRelationInfo() instanceof ViewInfo` (was
`getTableInfo() instanceof ViewInfo`).
Callers updated accordingly: `TableViewCatalog` default methods, `Analyzer`,
`RelationResolution`, `V1Table`, and the in-tree test catalogs.
### Why are the changes needed?
`ViewInfo IS-A TableInfo` is not a true relationship -- a view is not a
table. The inheritance forced all of `TableInfo`'s state into the shared
builder, leaking table-only operations onto the view surface. Modeling both as
siblings of `RelationInfo` removes the leak at compile time and keeps each
builder scoped to exactly what its kind needs, while preserving the
`MetadataTable` carrier that the `loadTableOrView` perf path relies on.
### Does this PR introduce _any_ user-facing change?
No. The affected APIs (`TableInfo`, `ViewInfo`, `MetadataTable`,
`TableViewCatalog`) are `@Evolving` and unreleased (`@since 4.2.0`).
### How was this patch tested?
Existing tests. `catalyst`, `sql/core`, and their test sources compile
against the refactored hierarchy; the in-tree `TableViewCatalog` test
implementations were updated to store the common `RelationInfo` type.
### Was this patch authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 4.8)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
