paul-rogers commented on a change in pull request #2026: DRILL-7330: Implement
metadata usage for all format plugins
URL: https://github.com/apache/drill/pull/2026#discussion_r392608220
##########
File path:
exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/scan/file/FileMetadataColumn.java
##########
@@ -65,6 +82,11 @@ public FileMetadataColumn(String name,
FileMetadataColumnDefn defn) {
@Override
public MetadataColumn resolve(FileMetadata fileInfo, VectorSource source,
int sourceIndex) {
- return new FileMetadataColumn(name(), defn, fileInfo, source, sourceIndex);
+ if (value() == null) {
+ return new FileMetadataColumn(name(), defn, fileInfo, source,
sourceIndex);
+ } else {
+ // case of metadata column, which should have null value independently
of its column definition
+ return new FileMetadataColumn(name(), defn, (String) null, source,
sourceIndex);
Review comment:
Please explain this a bit more. In the original implementation, the reader
is given a path to a file to read. The path and file name are broken apart and
passed to these implicit column objects. (I should rename them.) In what case
would the reader not know the name or path of the file it should read, and must
look the data up in the metastore? Did we add new columns that require going
out to the file system to gather a value? (I'm changing this area, so I want to
make sure I know the intent here.)
If this class will check the fs, then there is a chance the file has been
deleted. It will now be this class, rather than the reader, that detects
missing files. I would think we'd want to handle that further up the call
stack, then pass the resolved info into this class.
----------------------------------------------------------------
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]
With regards,
Apache Git Services
