gaborkaszab commented on code in PR #18486: URL: https://github.com/apache/iceberg/pull/18486#discussion_r4478034095
########## api/src/main/java/org/apache/iceberg/HasReferencedFiles.java: ########## @@ -0,0 +1,29 @@ +/* + * 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.iceberg; + +/** A {@link ScanTask} that can list the content files it reads. */ +public interface HasReferencedFiles { + /** + * Returns all content files that must be read to process this task + * + * @return the content files referenced by this task + */ + Iterable<ContentFile<?>> referencedFiles(); Review Comment: There is no common parent of `DataFile`, `DeleteFile` and `ColumnFile` that we could use here, unfortunately. We have a couple of ways to solve this: 1) In the future if we introduce something like an `EncryptedFile` we could introduce a variation that returns the common interface, but for now we don't have anything like that. This might be a long-term solution. 2) We could adapt/wrap a `ColumnFile` to seem like a `ContentFile` and then we can return them as part of the list. Might seem a nasty workaround, I probably wouldn't be in favor of this option. 3) Technically, `ContentFile` contains the column files. In the decryptor we can get the `ColumnFile`s if a file is a `DataFile` instance. I think I'd prefer 3) because then there is a single place where we change the code for column file coverage and we get it everywhere, where the decryptor is used. About the other question: I have considered that option too. What I wanted to avoid is to have a default implementation that compiles and runs but then silently misses some files in case of an implementation that doesn't override it. E.g. `ContentScanTask` returns `file()`, then `DeletedRowsScanTask` forgets to override to add `addedDeletes()`, and `existingDeletes()`. Also with that, we would need to check if input is an instance of `ContentScanTask`. Checking for `HasReferencedFiles` seems more verbose and cleaner to understand what we are doing. ########## core/src/main/java/org/apache/iceberg/encryption/InputFilesDecryptor.java: ########## @@ -49,7 +50,7 @@ public InputFilesDecryptor( } public static InputFilesDecryptor fromTasks( Review Comment: Ahh, I always forget to add the javadoc comment to this public method, thanks for pointing that out and for the suggestion. I applied it, except the exception part because that seemed to much of an implementation detail to me to leak through Javadoc. ########## spark/v4.2/spark/src/main/java/org/apache/iceberg/spark/source/BaseReader.java: ########## @@ -148,12 +148,8 @@ public boolean next() throws IOException { } } } catch (IOException | RuntimeException e) { - if (currentTask != null && !currentTask.isDataTask()) { - String filePaths = - referencedFiles(currentTask) - .map(ContentFile::location) - .collect(Collectors.joining(", ")); - LOG.error("Error reading file(s): {}", filePaths, e); + if (currentTask instanceof ContentScanTask<?> contentTask && !currentTask.isDataTask()) { + LOG.error("Error reading file: {}", contentTask.file().location(), e); Review Comment: Indeed, thanks for spotting this! -- 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]
