ryan-johnson-databricks commented on code in PR #40885:
URL: https://github.com/apache/spark/pull/40885#discussion_r1174017427
##########
sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/FileFormat.scala:
##########
@@ -203,6 +203,21 @@ trait FileFormat {
* method. Technically, a file format could choose suppress them, but that
is not recommended.
*/
def metadataSchemaFields: Seq[StructField] = FileFormat.BASE_METADATA_FIELDS
+
+ /**
+ * The extractors to use when deriving file-constant metadata columns for
this file format.
+ *
+ * A scanner must derive each file-constant metadata field's value from each
[[PartitionedFile]]
+ * it processes. By default, the value is obtained by a direct lookup of the
column's name on
+ * [[PartitionedFile.otherConstantMetadataColumnValues]] (see
+ * [[FileFormat.getFileConstantMetadataColumnValue]]). However,
implementations can override this
+ * method in order to provide more sophisticated lazy extractors (e.g. in
case the column value is
+ * complicated or expensive to compute).
Review Comment:
That wording was intentional... the simple way is usually the right way and
thus should be the default. If something special is going on, I'd prefer it to
be highly visible.
Put another way -- if the column _can_ be populated by simply pulling its
value from the map, why should we encourage the use of an extractor? Especially
when the map is the only part of `PartitionedFile` whose content a `FileIndex`
has any real control over?
An alternative would be to require all constant metadata columns to provide
extractors, and define a default extractor that just goes to the map... but
this seems like extra boilerplate for no real benefit?
(I originally wanted to just embed the extractor in the attribute definition
directly, but attribute/struct metadata cannot store code and IMO that's a wise
design decision we shouldn't 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: reviews-unsubscr...@spark.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
