You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@drill.apache.org by "Paul Rogers (JIRA)" <ji...@apache.org> on 2017/12/24 00:49:07 UTC
[jira] [Created] (DRILL-6060) JDBC-all excludes files required for
date/time vectors
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)
Re: [jira] [Created] (DRILL-6060) JDBC-all excludes files required
for date/time vectors
Posted by Gaurav Agarwal <ga...@gmail.com>.
On Dec 24, 2017 06:19, "Paul Rogers (JIRA)" <ji...@apache.org> 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)
>
Re: [jira] [Created] (DRILL-6060) JDBC-all excludes files required
for date/time vectors
Posted by Gaurav Agarwal <ga...@gmail.com>.
On Dec 24, 2017 06:19, "Paul Rogers (JIRA)" <ji...@apache.org> 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)
>