On Dec 24, 2017 06:19, "Paul Rogers (JIRA)" <[email protected]> wrote:
> 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) >
