-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-54683][SQL] Unify geo and time types blocking #53438
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
| } | ||
|
|
||
| create.tableSchema.foreach(f => TypeUtils.failWithIntervalType(f.dataType)) | ||
| TypeUtils.failUnsupportedDataType(create.tableSchema, SQLConf.get) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit off topic, but just follow how we block interval type for v2 catalogs, which we don't have any builtin impl in Spark yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you use a new JIRA ID instead of a follow-up, @cloud-fan ?
| createDeserializerForInstant(path) | ||
| case LocalDateTimeEncoder => | ||
| createDeserializerForLocalDateTime(path) | ||
| case LocalTimeEncoder if !SQLConf.get.isTimeTypeEnabled => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this missed before? Or a side-effect of unification (which becomes to miss in other layer)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's missed before and I found it when trying to unify the geo type blocking code.
| case TimestampEncoder(false) => createSerializerForSqlTimestamp(input) | ||
| case InstantEncoder(false) => createSerializerForJavaInstant(input) | ||
| case LocalDateTimeEncoder => createSerializerForLocalDateTime(input) | ||
| case LocalTimeEncoder if !SQLConf.get.isTimeTypeEnabled => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto.
| case LocalDateTimeEncoder => | ||
| createDeserializerForLocalDateTime(path) | ||
| case LocalTimeEncoder if !SQLConf.get.isTimeTypeEnabled => | ||
| throw org.apache.spark.sql.errors.QueryCompilationErrors.unsupportedTimeTypeError() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall we import org.apache.spark.sql.errors.QueryCompilationErrors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
geo type blocking does not import org.apache.spark.sql.AnalysisException either...
It's temporary and will be removed after we complete time type development. I think it's fine.
| case InstantEncoder(false) => createSerializerForJavaInstant(input) | ||
| case LocalDateTimeEncoder => createSerializerForLocalDateTime(input) | ||
| case LocalTimeEncoder if !SQLConf.get.isTimeTypeEnabled => | ||
| throw org.apache.spark.sql.errors.QueryCompilationErrors.unsupportedTimeTypeError() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto. import org.apache.spark.sql.errors.QueryCompilationErrors?
|
Could you fix the compilation error, @cloud-fan ? |
|
Given the current status, I believe we are able to merge this as 4.1.1 instead of blocking I'm going to proceed toward RC3 from the AS-IS |
|
yea it doesn't block 4.1 RC as time type is mostly blocked and users won't be able to use it in any meaningful workloads. |
|
Thank you, @cloud-fan . |
|
The test failure in |
What changes were proposed in this pull request?
This PR aims to refactor the code that blocks time and geo types.
Why are the changes needed?
code unification
Does this PR introduce any user-facing change?
no
How was this patch tested?
existing tests
Was this patch authored or co-authored using generative AI tooling?
no