drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Nadeau (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-3834) Remove requirement for fully resolved types in UDFs.
Date Thu, 24 Sep 2015 16:30:04 GMT

    [ https://issues.apache.org/jira/browse/DRILL-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14906599#comment-14906599

Jacques Nadeau commented on DRILL-3834:

Since Drill only uses the UDF function bodies (and extracts them using source), Drill doesn't
currently take advantage of the imports that may be expressed in the source file. It is easy
enough to retrieve these imports and include them in compilation. However, that would be ineffective
in this situation. This is because Drill composes a single class that uses many of these UDFs
simultaneously. If Drill just bulk-imported all the required class names, it would be likely
that the name conflicts would occur that the user couldn't work around (and would be very
confusing). A cleaner way is to rewrite the method blocks to have full references to required
classes. This can be looped in with the VisitReferenceType method of ModifiedUnparseVisitor.
However, we then need to do the full class resolution at this time (similar to what would
be done at compile time). The code already exists in UnitCompiler.getReferenceType() however
it is protected. We need to decide how to resolve this (or come up with another approach).

> Remove requirement for fully resolved types in UDFs.
> ----------------------------------------------------
>                 Key: DRILL-3834
>                 URL: https://issues.apache.org/jira/browse/DRILL-3834
>             Project: Apache Drill
>          Issue Type: Improvement
>          Components: Execution - Codegen
>            Reporter: Jacques Nadeau
> Right now, UDFs require the user to write code which include fully qualified types. This
makes UDFs harder to write and harder to read. We should update the functionality to avoid
this requirement.

This message was sent by Atlassian JIRA

View raw message