Uh oh!
There was an error while loading. Please reload this page.
Core: Extend ResolvingFileIO to support prefix-based operations - #8334
Conversation
f88ae6a to
0e52578CompareUh oh!
There was an error while loading. Please reload this page.
| .forEachRemaining( | ||
| partitioned -> { | ||
| Map<FileIO, List<String>> pathByFileIO = | ||
| Map<DelegateFileIO, List<String>> pathByFileIO = |
There was a problem hiding this comment.
We can just call the delegate directly now, I don't believe there is a need for this logic anymore
There was a problem hiding this comment.
do you think we should still batch here or would we want to essentially use the same implementation you had?
// peek at the first element to determine the type of FileIO
Iterator<String> originalIterator = pathsToDelete.iterator();
if (!originalIterator.hasNext()) {
return;
}
PeekingIterator<String> iterator = Iterators.peekingIterator(originalIterator);
DelegateFileIO fileIO = io(iterator.peek());
fileIO.deleteFiles(() -> iterator);
To me it seems like batching should probably be handled by the underlying FileIO implementation, but just wanted to see what others think?
There was a problem hiding this comment.
Actually, it is probably better to keep what you have as there may be multiple FileIO types involved, and the peek method wasn’t ideal.
Uh oh!
There was an error while loading. Please reload this page.
767280b to
a3c0eceCompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
RussellSpitzer
commented
Sep 13, 2023
leoluan2009
commented
Sep 14, 2023
@nastra@RussellSpitzer Should ADLSFileIO implement DelgateFileIO as GCSFileIO to make code clean and consistently? |
nastra
commented
Sep 14, 2023
@leoluan2009 yes it should, good catch. I've opened #8563 to address that |
No description provided.