rdblue commented on a change in pull request #1738: URL: https://github.com/apache/iceberg/pull/1738#discussion_r519072423
########## File path: spark3-extensions/src/main/scala/org/apache/spark/sql/execution/datasources/v2/OverwriteFilesExec.scala ########## @@ -0,0 +1,63 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +package org.apache.spark.sql.execution.datasources.v2 + +import collection.JavaConverters._ +import org.apache.spark.sql.catalyst.InternalRow +import org.apache.spark.sql.connector.read.SupportsReadFileFilter +import org.apache.spark.sql.connector.write.{BatchWrite, SupportsWriteFileFilter} +import org.apache.spark.sql.execution.SparkPlan + +case class OverwriteFilesExec(batchWrite: BatchWrite, queryExec: SparkPlan) extends V2TableWriteExec { + + // override child so that we can properly plan queryExec without executing the file filter + override def child: SparkPlan = queryExec + + // TODO: doPrepare is NOT invoked by V2TableWriteExec + // TODO: it should be ok if at least reader or writer supports dynamic file filter + override lazy val query: SparkPlan = { + batchWrite match { + case w: SupportsWriteFileFilter => + val dynamicFileFilters = queryExec.collect { case s: DynamicFileFilterExec => s } Review comment: The way this works seems a little strange to me because it finds another exec node further down in the tree, and then uses that node's children. Instead, I would expect the execution here to happen on that node, where `doPrepare` will be called. I think the only reason to do it this way is to have a reference to `SupportsWriteFileFilter` that is further up the plan tree. If we relied on the write and the scan to coordinate because they are part of the same replace operation, then we could make this a bit cleaner. What about moving this to `DynamicFileFilter.doPrepare`, where it will check whether the scan is `SupportsReadFileFilter`, if so execute the query, and call `filterFiles`? ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
