[
https://issues.apache.org/jira/browse/DRILL-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045940#comment-15045940
]
ASF GitHub Bot commented on DRILL-4123:
---------------------------------------
Github user jaltekruse commented on the pull request:
https://github.com/apache/drill/pull/293#issuecomment-162696095
One other point here, the issue with fully qualified names actually
shouldn't be a problem in the usual usage of this function. The function was
only designed to be evaluated at planning time with the interpreter, not with
the full code compilation model in the project operator. While not ideal, the
expected error that should be hit if this function is used in a select list is
here in the FragmentContext when we go to populate the injected
PartitionExplorer.
https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/ops/FragmentContext.java#L458
Has there been work to make partition pruning run the full code generation
based expression evaluation? I would consider anyone hitting code generation
issues with this function to be misusing it, I agree with fixing this poor
error, but anyone executing this function outside of partition pruning is going
to be running a very expensive operation for each record in their dataset and I
can't think of a use case for it.
> DirectoryExplorers should refer to fully qualified variable names
> -----------------------------------------------------------------
>
> Key: DRILL-4123
> URL: https://issues.apache.org/jira/browse/DRILL-4123
> Project: Apache Drill
> Issue Type: Bug
> Reporter: Hanifi Gunes
> Assignee: Hanifi Gunes
>
> Execution fails with {code}CompileException: Line 75, Column 70: Unknown
> variable or type "FILE_SEPARATOR"{code} in case a directory explorer is used
> in a projection. Also FILE_SEPARATOR should not be platform dependent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
