Paul Rogers created DRILL-6060:
----------------------------------
Summary: JDBC-all excludes files required for date/time vectors
Key: DRILL-6060
URL: https://issues.apache.org/jira/browse/DRILL-6060
Project: Apache Drill
Issue Type: Bug
Affects Versions: 1.12.0
Reporter: Paul Rogers
Assignee: Paul Rogers
Fix For: 1.13.0
The vector package contains the file
{{org.apache.drill.exec.expr.fn.impl.DateUtility}}. It contains formatting code
along with a set of date constants (such as the number of hours in a day.) The
date constants are used in the generated value vector code, such as for the
{{IntervalVector}} class:
{code}
public StringBuilder getAsStringBuilder(int index) {
...
final int years = (months /
org.apache.drill.exec.expr.fn.impl.DateUtility.yearsToMonths);
months = (months %
org.apache.drill.exec.expr.fn.impl.DateUtility.yearsToMonths);
{code}
Thus, the {{DateUtility}} class is required in order for the date/time vectors
to work.
Yet, recent changes to the JDBC driver now excludes the package that contains
the {{DateUtility}} class. In {{dependency-reduced-pom.xml}}:
{code}
<exclude>org/apache/drill/exec/expr/fn/**</exclude>
{code}
A refactoring exercised moved more of the date/time code out of generated code
and into the {{DateUtility}} class, so that the code can be reused. The result
are runtime errors in unit tests.
{noformat}
Caused by: java.lang.NoClassDefFoundError:
oadd/org/apache/drill/exec/expr/fn/impl/DateUtility
at
oadd.org.apache.drill.exec.vector.IntervalDayVector$Accessor.getObject(IntervalDayVector.java:450)
at
oadd.org.apache.drill.exec.vector.accessor.IntervalDayAccessor.getObject(IntervalDayAccessor.java:125)
{noformat}
Since the intent is to exclude functions only needed by Drill execution, the
solution is to move the code required by vectors out of the {{fn}} package. The
safe bet is to put it in the {{org.apache.drill.exec.vector}} which can't be
excluded (it includes the value vector code.)
The larger issue is that the concept of excluding bits of Drill code is
problematic: there is no good way to ensure that the code is not needed.
The traditional (and reliable) solution is to design a client-only library
which is designed to include only the required dependences. Build up the list
of dependencies from zero (as is common practice in Maven) rather than try to
add things then throw them overboard.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
