[
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 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.
was:
Follow-up to SPARK-58389 ("Pass all options while loading tables"), which
forwarded
all user-specified options to TableCatalog.loadTable(Identifier, TableContext,
CaseInsensitiveStringMap) on the table read path.
That change does not cover the RelationCatalog single-RPC read path. A
RelationCatalog
(a connector that exposes both tables and views in one identifier namespace) is
resolved
through RelationCatalog.loadRelation(Identifier) -- a single call that answers
"table or
view?" in one round trip. For such a catalog this is the primary plain-read
path, and it
currently does not receive the user options, so a connector cannot see them when
producing the Table/View metadata for a plain read.
This is the direct analogue of SPARK-58389 for the single-RPC path. Add
RelationCatalog.loadRelation(Identifier, CaseInsensitiveStringMap) with a
default
implementation that ignores the options and delegates to
loadRelation(Identifier) --
so existing connectors are unaffected -- and forward the user options to it
from the
resolver's plain-read branch (which fires only when there is no time travel and
no write
privileges; both apply to tables only and route through the loadTable path
instead).
This is API completeness for the combined table+view catalog: it lets such a
catalog
customize the returned relation from the read options at metadata-load time,
symmetric
to what SPARK-58389 enables for table-only catalogs. The feature has not been
released.
Summary: Pass table state options while loading relations (was: Pass
all options while loading relations)
> 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 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
