[ 
https://issues.apache.org/jira/browse/SPARK-51899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yihong He updated SPARK-51899:
------------------------------
    Description: 
There are risks associated with working with partial data, especially when 
unaware that some tables are broken. Throwing an exception instead provides a 
clear indication that something is wrong.

Instead we can use error handling rules to determine the proper behavior on a 
case-by-case basis. SparkThrowable should be sufficient to capture the cases we 
want to handle.

  was:
Swallowing all non-fatal errors and returning partial results can lead to 
inconsistent outcomes, especially in cases involving transient errors (e.g., a 
table may return full results in {{{}listTables(){}}}, but then return partial 
results in a subsequent call due to a transient error).

Additionally, the {{tableType}} field in the {{Table}} class is not nullable. 
While it is technically possible to set {{tableType}} to {{{}null{}}}, doing so 
violates the expectations of the {{Table}} class. This may surprise people.

To address these issues, we can implement an error allowlist based on SQL 
states for non-transient errors and avoid returning results for those tables, 
rather than returning partial results when non-transient occur.


> Implement error handling rules for spark.catalog.listTables()
> -------------------------------------------------------------
>
>                 Key: SPARK-51899
>                 URL: https://issues.apache.org/jira/browse/SPARK-51899
>             Project: Spark
>          Issue Type: Improvement
>          Components: Connect
>    Affects Versions: 4.1.0
>            Reporter: Yihong He
>            Priority: Minor
>              Labels: pull-request-available
>
> There are risks associated with working with partial data, especially when 
> unaware that some tables are broken. Throwing an exception instead provides a 
> clear indication that something is wrong.
> Instead we can use error handling rules to determine the proper behavior on a 
> case-by-case basis. SparkThrowable should be sufficient to capture the cases 
> we want to handle.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

Reply via email to