bmorck commented on code in PR #17499:
URL: https://github.com/apache/iceberg/pull/17499#discussion_r3755178412
##########
spark/v4.1/spark-extensions/src/main/scala/org/apache/spark/sql/catalyst/analysis/ResolveViews.scala:
##########
@@ -111,16 +119,72 @@ case class ResolveViews(spark: SparkSession) extends
Rule[LogicalPlan] with Look
// Apply the field aliases and column comments
// This logic differs from how Spark handles views in
SessionCatalog.fromCatalogTable.
- // This is more strict because it doesn't allow resolution by field name.
+ // BINDING is more strict because it doesn't allow resolution by field
name. COMPENSATION and
+ // TYPE_EVOLUTION coerce as SessionCatalog.castColToType does for those
modes. Every mode keeps
+ // the stored name and metadata; only the coercion differs.
+ val mode = viewSchemaMode
val aliases = view.schema.fields.zipWithIndex.map { case (expected, pos) =>
val attr = GetColumnByOrdinal(pos, expected.dataType)
- Alias(UpCast(attr, expected.dataType), expected.name)(explicitMetadata =
- Some(expected.metadata))
+ val coerced =
+ if (mode == SparkSQLProperties.VIEW_SCHEMA_MODE_COMPENSATION) {
+ Cast(attr, expected.dataType, ansiEnabled = true)
+ } else if (mode == SparkSQLProperties.VIEW_SCHEMA_MODE_TYPE_EVOLUTION)
{
+ attr
Review Comment:
On your other question, when we enable `TYPE_EVOLUTION` mode that will
create a mismatch between what is returned and what the describe view has. For
the default `BINDING` mode this wouldn't be the case
Let me know what you think. I'm thinking that since `TYPE_EVOLUTION` is not
the default and is up to the user's discretion to set, it may not be an issue
if the type reported from the schema mismatches. The user in this case would
set TYPE_EVOLUTION likely understanding that it will create drift here. And
that this mode was the primary motivation for this change
--
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]
