[
https://issues.apache.org/jira/browse/SPARK-58392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yan Yan updated SPARK-58392:
----------------------------
Description:
Follow-up to SPARK-58389, which lets catalogs declare options that affect table
state through {{TableCatalog.tableStateOptionKeys()}}. Spark forwards only that
declared projection to {{TableCatalog.loadTable(Identifier, TableContext,
CaseInsensitiveStringMap)}} and retains the complete user option map on the
resolved relation for scan planning.
{{RelationCatalog.loadRelation(Identifier)}} remains the single-RPC path for
ordinary reads with no table-state options, time travel, or write privileges.
When table-state options are present, relation resolution uses
{{TableCatalog.loadTable(Identifier, TableContext, CaseInsensitiveStringMap)}}
for the table side. If the identifier is not a table, ordinary reads may fall
back to {{ViewCatalog.loadView(Identifier)}}. Time-travel and write-privilege
loads remain table-only.
The shared table lookup matches table identity and declared table-state
options, while each resolved relation retains its complete option map. This
change adds no new {{RelationCatalog}} API.
PR: https://github.com/apache/spark/pull/57585
was:
Follow-up to SPARK-58389, which lets catalogs declare options that affect table
state through TableCatalog.tableStateOptionKeys(). Spark forwards only that
declared projection while loading a table and retains the complete user option
map for scan planning.
That contract does not cover the RelationCatalog single-RPC read path.
RelationCatalog resolves an identifier that may be either a table or a view
through loadRelation(Identifier), which currently cannot receive table-state
options.
Add RelationCatalog.loadRelation(Identifier, CaseInsensitiveStringMap). Its
default implementation ignores the state options and delegates to
loadRelation(Identifier), preserving compatibility for existing connectors.
For a plain read, RelationResolution passes only the catalog-declared
table-state option projection to the new overload. Because the relation kind is
known only after loadRelation returns, Spark applies the same projection when
the identifier resolves to a table or a view. The complete user option map
remains on the resolved relation for scan planning.
The options-aware RelationCatalog loadTable default also delegates plain reads
to the new overload so execution refresh and other empty-context table loads
preserve the selected state. Time travel and write-privilege loads remain
table-only and continue through TableCatalog dispatch.
> Pass table state options while loading relations
> ------------------------------------------------
>
> Key: SPARK-58392
> URL: https://issues.apache.org/jira/browse/SPARK-58392
> Project: Spark
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 4.2.0
> Reporter: Yan Yan
> Priority: Minor
> Labels: pull-request-available
>
> Follow-up to SPARK-58389, which lets catalogs declare options that affect
> table state through {{TableCatalog.tableStateOptionKeys()}}. Spark forwards
> only that declared projection to {{TableCatalog.loadTable(Identifier,
> TableContext, CaseInsensitiveStringMap)}} and retains the complete user
> option map on the resolved relation for scan planning.
> {{RelationCatalog.loadRelation(Identifier)}} remains the single-RPC path for
> ordinary reads with no table-state options, time travel, or write privileges.
> When table-state options are present, relation resolution uses
> {{TableCatalog.loadTable(Identifier, TableContext,
> CaseInsensitiveStringMap)}} for the table side. If the identifier is not a
> table, ordinary reads may fall back to {{ViewCatalog.loadView(Identifier)}}.
> Time-travel and write-privilege loads remain table-only.
> The shared table lookup matches table identity and declared table-state
> options, while each resolved relation retains its complete option map. This
> change adds no new {{RelationCatalog}} API.
> PR: https://github.com/apache/spark/pull/57585
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
