[jira] [Issue Comment Deleted] (DRILL-5141) Difference in output date format on sqlline vs Drill's Web UI
[
https://issues.apache.org/jira/browse/DRILL-5141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitalii Diravka updated DRILL-5141:
---
Comment: was deleted
(was: Once [DRILL-5332|https://issues.apache.org/jira/browse/DRILL-5332] is
resolved, this issue will gone.)
> Difference in output date format on sqlline vs Drill's Web UI
> -
>
> Key: DRILL-5141
> URL: https://issues.apache.org/jira/browse/DRILL-5141
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.9.0
>Reporter: Khurram Faraaz
>Priority: Minor
> Fix For: 1.15.0
>
>
> Difference in output date format on sqlline vs Drill's Web UI
> Drill 1.9.0 git commit ID : 4c1b420b
> From sqlline prompt
> {noformat}
> 0: jdbc:drill:schema=dfs.tmp> SELECT cast('2016/09/22' as date) FROM
> (VALUES(1));
> +-+
> | EXPR$0|
> +-+
> | 2016-09-22 |
> +-+
> 1 row selected (0.474 seconds)
> {noformat}
> The same query returns a date in a different output format on the web UI
> {noformat}
> 2016-09-22T00:00:00.000Z
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (DRILL-5141) Difference in output date format on sqlline vs Drill's Web UI
[
https://issues.apache.org/jira/browse/DRILL-5141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16152624#comment-16152624
]
Vitalii Diravka edited comment on DRILL-5141 at 12/24/18 7:03 PM:
--
Once [DRILL-5332|https://issues.apache.org/jira/browse/DRILL-5332] is resolved,
this issue will gone.
was (Author: vitalii):
Once [DRILL-5332|https://issues.apache.org/jira/browse/DRILL-5141] is resolved,
this issue will gone.
> Difference in output date format on sqlline vs Drill's Web UI
> -
>
> Key: DRILL-5141
> URL: https://issues.apache.org/jira/browse/DRILL-5141
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.9.0
>Reporter: Khurram Faraaz
>Priority: Minor
> Fix For: 1.15.0
>
>
> Difference in output date format on sqlline vs Drill's Web UI
> Drill 1.9.0 git commit ID : 4c1b420b
> From sqlline prompt
> {noformat}
> 0: jdbc:drill:schema=dfs.tmp> SELECT cast('2016/09/22' as date) FROM
> (VALUES(1));
> +-+
> | EXPR$0|
> +-+
> | 2016-09-22 |
> +-+
> 1 row selected (0.474 seconds)
> {noformat}
> The same query returns a date in a different output format on the web UI
> {noformat}
> 2016-09-22T00:00:00.000Z
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (DRILL-6922) QUERY-level options are shown on Profiles tab
[ https://issues.apache.org/jira/browse/DRILL-6922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728468#comment-16728468 ] Arina Ielchiieva edited comment on DRILL-6922 at 12/24/18 5:56 PM: --- Merged into master with commit id 44f17eaf1b9489fc16fadee0178e975f6aff5185. was (Author: arina): Merged into Apache master with commit id 44f17eaf1b9489fc16fadee0178e975f6aff5185. > QUERY-level options are shown on Profiles tab > - > > Key: DRILL-6922 > URL: https://issues.apache.org/jira/browse/DRILL-6922 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Bohdan Kazydub >Assignee: Arina Ielchiieva >Priority: Blocker > Labels: doc-impacting, ready-to-commit > Fix For: 1.15.0 > > > Option `exec.return_result_set_for_ddl` is shown on Web UI's Profiles even > when it was not set explicitly. The issue is because the option is being set > on query level internally. > *For documentation* > Option `exec.return_result_set_for_ddl` was renamed to > `exec.query.return_result_set_for_ddl`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-5360) Timestamp type documented as UTC, implemented as local time
[
https://issues.apache.org/jira/browse/DRILL-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitalii Diravka updated DRILL-5360:
---
Fix Version/s: (was: 1.16.0)
2.0.0
> Timestamp type documented as UTC, implemented as local time
> ---
>
> Key: DRILL-5360
> URL: https://issues.apache.org/jira/browse/DRILL-5360
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Paul Rogers
>Assignee: Bohdan Kazydub
>Priority: Critical
> Fix For: 2.0.0
>
>
> The Drill documentation implies that the {{Timestamp}} type is in UTC:
> bq. JDBC timestamp in year, month, date hour, minute, second, and optional
> milliseconds format: -MM-dd HH:mm:ss.SSS. ... TIMESTAMP literals: Drill
> stores values in Coordinated Universal Time (UTC). Drill supports time
> functions in the range 1971 to 2037. ... Drill does not support TIMESTAMP
> with time zone.
> The above is ambiguous. The first part talks about JDBC timestamps. From the
> JDK Javadoc:
> bq. Timestamp: A thin wrapper around java.util.Date. ... Date class is
> intended to reflect coordinated universal time (UTC)...
> So, a JDBC timestamp is intended to represent time in UTC. (The "indented to
> reflect" statement leaves open the possibility of misusing {{Date}} to
> represent times in other time zones. This was common practice in early Java
> development and was the reason for the eventual development of the Joda, then
> Java 8 date/time classes.)
> The Drill documentation implies that timestamp *literals* are in UTC, but a
> careful read of the documentation does allow an interpretation that the
> internal representation can be other than UTC. If this is true, then we would
> also rely on a liberal reading of the Java `Timestamp` class to also not be
> UTC. (Or, we rely on the Drill JDBC driver to convert from the (unknown)
> server time zone to a UTC value returned by the Drill JDBC client.)
> Still, a superficial reading (and common practice) would suggest that a Drill
> Timestamp should be in UTC.
> However, a test on a Mac, with an embedded Drillbit (run in the Pacific time
> zone, with Daylight Savings Time in effect) shows that the Timestamp binary
> value is actual local time:
> {code}
> long before = System.currentTimeMillis();
> long value = getDateValue(client, "SELECT NOW() FROM (VALUES(1))" );
> double hrsDiff = (value - before) / (1000.00 * 60 * 60);
> System.out.println("Hours: " + hrsDiff);
> {code}
> The above gets the actual UTC time from Java. Then, it runs a query that gets
> Drill's idea of the current time using the {{NOW()}} function. (The
> {{getDateValue}} function uses the new test framework to access the actual
> {{long}} value from the returned value vector.) Finally, we compute the
> difference between the two times, converted to hours. Output:
> {code}
> Hours: -6.975
> {code}
> As it turns out, this is the difference between UTC and PDT. So, the time is
> in local time, not UTC.
> Since the documentation and implementation are both ambiguous, it is hard to
> know the intent of the Drill Timestamp. Clearly, common practice is to use
> UTC. But, there is wiggle-room.
> If the Timestamp value is supposed to be local time, then Drill should
> provide a function to return the server's time zone offset (in ms) from UTC
> so that the client can to the needed local-to-UTC conversion to get a true
> timestamp.
> On the other hand, if the Timestamp is supposed to be UTC (per common
> practice), then {{NOW()}} should not report local time, it should return UTC.
> Further, if {{NOW()}} returns local time, but Timestamp literals are UTC,
> then it is hard to see how any query can be rationally written if one
> timestamp value is local, but a literal is UTC.
> So, job #1 is to define the Timestamp semantics. Then, use that to figure out
> where the bug lies to make implementation consistent with documentation (or
> visa-versa.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DRILL-5360) Timestamp type documented as UTC, implemented as local time
[
https://issues.apache.org/jira/browse/DRILL-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728455#comment-16728455
]
Vitalii Diravka commented on DRILL-5360:
[~priteshm]
Drill has a lot of issues and inconsistencies connected to the "time/date"
datatypes and Time Zones. It is necessary to lead it to the general form.
Things to be done:
* Design doc for Drill Date, Time, Timestamp;
* Revisiting and leading to the SQL standard of Drill "date/time" datatypes.
Reading, converting, storing internally (ValueVectors), extracting and
representing of "date/time" datatypes:
** Consistency between different data sources (parquet, csv ...)
** Date, time should not rely in particular time zone
** Issues connected to representing of "date/time" data types for JDBC (server
and client are in different time zones).
** Issues connected to CAST operator
** Improvement of "date/time" output (style)
** Considering of new data type - TimestampTZ
([PostgreSQL|https://www.postgresql.org/docs/9.1/static/datatype-datetime.html]
has equivalent TIMESTAMP WITH TIME ZONE and Calcite has -
TIMESTAMP_WITH_LOCAL_TIME_ZONE);
* Moving from [Joda Time|http://www.joda.org/joda-time/] to [Java SE 8 Date
and
Time|http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html]
These changes are not backward-compatible. Therefore they should be implemented
along with design document for the next Drill major version. It seems the best
one is 2.0.0 version.
> Timestamp type documented as UTC, implemented as local time
> ---
>
> Key: DRILL-5360
> URL: https://issues.apache.org/jira/browse/DRILL-5360
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Paul Rogers
>Assignee: Bohdan Kazydub
>Priority: Critical
> Fix For: 2.0.0
>
>
> The Drill documentation implies that the {{Timestamp}} type is in UTC:
> bq. JDBC timestamp in year, month, date hour, minute, second, and optional
> milliseconds format: -MM-dd HH:mm:ss.SSS. ... TIMESTAMP literals: Drill
> stores values in Coordinated Universal Time (UTC). Drill supports time
> functions in the range 1971 to 2037. ... Drill does not support TIMESTAMP
> with time zone.
> The above is ambiguous. The first part talks about JDBC timestamps. From the
> JDK Javadoc:
> bq. Timestamp: A thin wrapper around java.util.Date. ... Date class is
> intended to reflect coordinated universal time (UTC)...
> So, a JDBC timestamp is intended to represent time in UTC. (The "indented to
> reflect" statement leaves open the possibility of misusing {{Date}} to
> represent times in other time zones. This was common practice in early Java
> development and was the reason for the eventual development of the Joda, then
> Java 8 date/time classes.)
> The Drill documentation implies that timestamp *literals* are in UTC, but a
> careful read of the documentation does allow an interpretation that the
> internal representation can be other than UTC. If this is true, then we would
> also rely on a liberal reading of the Java `Timestamp` class to also not be
> UTC. (Or, we rely on the Drill JDBC driver to convert from the (unknown)
> server time zone to a UTC value returned by the Drill JDBC client.)
> Still, a superficial reading (and common practice) would suggest that a Drill
> Timestamp should be in UTC.
> However, a test on a Mac, with an embedded Drillbit (run in the Pacific time
> zone, with Daylight Savings Time in effect) shows that the Timestamp binary
> value is actual local time:
> {code}
> long before = System.currentTimeMillis();
> long value = getDateValue(client, "SELECT NOW() FROM (VALUES(1))" );
> double hrsDiff = (value - before) / (1000.00 * 60 * 60);
> System.out.println("Hours: " + hrsDiff);
> {code}
> The above gets the actual UTC time from Java. Then, it runs a query that gets
> Drill's idea of the current time using the {{NOW()}} function. (The
> {{getDateValue}} function uses the new test framework to access the actual
> {{long}} value from the returned value vector.) Finally, we compute the
> difference between the two times, converted to hours. Output:
> {code}
> Hours: -6.975
> {code}
> As it turns out, this is the difference between UTC and PDT. So, the time is
> in local time, not UTC.
> Since the documentation and implementation are both ambiguous, it is hard to
> know the intent of the Drill Timestamp. Clearly, common practice is to use
> UTC. But, there is wiggle-room.
> If the Timestamp value is supposed to be local time, then Drill should
> provide a function to return the server's time zone offset (in ms) from UTC
> so that the client can to the needed local-to-UTC conversion to get a true
> timestamp.
> On the other hand, if the Timestamp
[jira] [Created] (DRILL-6927) Query fails when hive table with timestamp data is queried with enabled int96_as_timestamp and optimize_scan_with_native_reader options
Volodymyr Vysotskyi created DRILL-6927:
--
Summary: Query fails when hive table with timestamp data is
queried with enabled int96_as_timestamp and optimize_scan_with_native_reader
options
Key: DRILL-6927
URL: https://issues.apache.org/jira/browse/DRILL-6927
Project: Apache Drill
Issue Type: Bug
Affects Versions: 1.14.0
Reporter: Volodymyr Vysotskyi
Fix For: Future
Steps to reproduce:
1. Create hive table with timestamp column:
{code:sql}
create table test_timestamp stored as PARQUET as select timestamp '2018-01-01
12:12:12.123' as c1;
{code}
2. Enable {{store.parquet.reader.int96_as_timestamp}} and
{{store.hive.parquet.optimize_scan_with_native_reader}}:
{code:sql}
set `store.parquet.reader.int96_as_timestamp`=true;
set `store.hive.parquet.optimize_scan_with_native_reader`=true;
{code}
3. Query hive table using Drill:
{code:sql}
select * from hive.test_timestamp;
{code}
Query fails with error:
{noformat}
Error: SYSTEM ERROR: SchemaChangeException: Failure while trying to materialize
incoming schema. Errors:
Error in expression at index -1. Error: Missing function implementation:
[convert_fromtimestamp_impala(TIMESTAMP-OPTIONAL)]. Full expression: --UNKNOWN
EXPRESSION--..
Fragment 0:0
{noformat}
Stack trace:
{noformat}
Error in expression at index -1. Error: Missing function implementation:
[convert_fromtimestamp_impala(TIMESTAMP-OPTIONAL)]. Full expression: --UNKNOWN
EXPRESSION--..
at
org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.setupNewSchemaFromInput(ProjectRecordBatch.java:498)
~[drill-java-exec-1.15.0-SNAPSHOT.jar:1.15.0-SNAPSHOT]
at
org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.setupNewSchema(ProjectRecordBatch.java:583)
~[drill-java-exec-1.15.0-SNAPSHOT.jar:1.15.0-SNAPSHOT]
at
org.apache.drill.exec.record.AbstractUnaryRecordBatch.innerNext(AbstractUnaryRecordBatch.java:101)
~[drill-java-exec-1.15.0-SNAPSHOT.jar:1.15.0-SNAPSHOT]
at
org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext(ProjectRecordBatch.java:143)
~[drill-java-exec-1.15.0-SNAPSHOT.jar:1.15.0-SNAPSHOT]
at
org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:186)
~[drill-java-exec-1.15.0-SNAPSHOT.jar:1.15.0-SNAPSHOT]
at
org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:104)
~[drill-java-exec-1.15.0-SNAPSHOT.jar:1.15.0-SNAPSHOT]
at
org.apache.drill.exec.physical.impl.ScreenCreator$ScreenRoot.innerNext(ScreenCreator.java:83)
~[drill-java-exec-1.15.0-SNAPSHOT.jar:1.15.0-SNAPSHOT]
at
org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:94)
~[drill-java-exec-1.15.0-SNAPSHOT.jar:1.15.0-SNAPSHOT]
at
org.apache.drill.exec.work.fragment.FragmentExecutor$1.run(FragmentExecutor.java:297)
~[drill-java-exec-1.15.0-SNAPSHOT.jar:1.15.0-SNAPSHOT]
at
org.apache.drill.exec.work.fragment.FragmentExecutor$1.run(FragmentExecutor.java:284)
~[drill-java-exec-1.15.0-SNAPSHOT.jar:1.15.0-SNAPSHOT]
at java.security.AccessController.doPrivileged(Native Method)
~[na:1.8.0_141]
at javax.security.auth.Subject.doAs(Subject.java:422) ~[na:1.8.0_141]
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1669)
~[hadoop-common-2.7.0-mapr-1808.jar:na]
at
org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:284)
[drill-java-exec-1.15.0-SNAPSHOT.jar:1.15.0-SNAPSHOT]
... 4 common frames omitted
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6921) Add button to reset Options filter
[ https://issues.apache.org/jira/browse/DRILL-6921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva updated DRILL-6921: Description: Currently we have ability to search options or use quick filter on Web UI. To reset the filter, user needs to delete input from the search pane manually. It would be nice if we had Reset button. Also we can consider leaving filter after option update / reset rather then reloading page without filtering. was:Currently we have ability to search options or use quick filter on Web UI. To reset the filter, user needs to delete input from the search pane manually. It would be nice if we had Reset button. > Add button to reset Options filter > -- > > Key: DRILL-6921 > URL: https://issues.apache.org/jira/browse/DRILL-6921 > Project: Apache Drill > Issue Type: Improvement >Affects Versions: 1.15.0 >Reporter: Arina Ielchiieva >Assignee: Kunal Khatua >Priority: Major > Fix For: 1.16.0 > > > Currently we have ability to search options or use quick filter on Web UI. To > reset the filter, user needs to delete input from the search pane manually. > It would be nice if we had Reset button. > Also we can consider leaving filter after option update / reset rather then > reloading page without filtering. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DRILL-6926) "java.io.IOException: Stream closed" warning from Drill RDBMS tests
Vitalii Diravka created DRILL-6926:
--
Summary: "java.io.IOException: Stream closed" warning from Drill
RDBMS tests
Key: DRILL-6926
URL: https://issues.apache.org/jira/browse/DRILL-6926
Project: Apache Drill
Issue Type: Bug
Components: Tools, Build Test
Affects Versions: 1.14.0
Reporter: Vitalii Diravka
Fix For: Future
Drill RDBMS integration tests show warnings in the process of running:
{code:java}
[INFO] --- jcabi-mysql-maven-plugin:0.9:stop (mysql-test) @ drill-jdbc-storage
---
[INFO] Stopping embedded Derby database
[INFO] #stop(34374): in 313.08µs
[INFO] #reusedExistingDatabase(): false in 14.77µs
[INFO] set Maven property jcabi.reused.database = false
[WARNING] escalated exception: java.lang.IllegalStateException:
java.io.IOException: Stream closed
at com.jcabi.log.VerboseRunnable$1.run(VerboseRunnable.java:139)
at com.jcabi.log.VerboseRunnable.run(VerboseRunnable.java:198)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: Stream closed
at
java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:170)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:283)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.
{code}
It relates to
[jcabi-mysql-maven-plugin|https://github.com/jcabi/jcabi-mysql-maven-plugin].
The issue was resolved for a long time ago for
_com.jcabi:jcabi-mysql-maven-plugin:1.0-SNAPSHOT_ version:
[https://github.com/jcabi/jcabi-mysql-maven-plugin/issues/30]
[https://github.com/jcabi/jcabi-mysql-maven-plugin/pull/53]
[http://www.rultor.com/t/1391-67978465]
But the last version of this plugin in Maven repo is
[0.9|https://mvnrepository.com/artifact/com.jcabi/jcabi-mysql-maven-plugin]
To solve the issue it is necessary to update the plugin version, once 1.0
version is released and check that all Drill tests pass without failures and
this warning.
To run tests use:
_mvn clean install -pl contrib/storage-jdbc_ to run tests on 1.15.0 Drill
version and
_mvn integration-test failsafe:integration-test -pl contrib/storage-jdbc_ on
1.14.0 Drill version and below.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6922) QUERY-level options are shown on Profiles tab
[ https://issues.apache.org/jira/browse/DRILL-6922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitalii Diravka updated DRILL-6922: --- Labels: doc-impacting ready-to-commit (was: doc-impacting) > QUERY-level options are shown on Profiles tab > - > > Key: DRILL-6922 > URL: https://issues.apache.org/jira/browse/DRILL-6922 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Bohdan Kazydub >Assignee: Arina Ielchiieva >Priority: Blocker > Labels: doc-impacting, ready-to-commit > Fix For: 1.15.0 > > > Option `exec.return_result_set_for_ddl` is shown on Web UI's Profiles even > when it was not set explicitly. The issue is because the option is being set > on query level internally. > *For documentation* > Option `exec.return_result_set_for_ddl` was renamed to > `exec.query.return_result_set_for_ddl`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-6922) QUERY-level options are shown on Profiles tab
[ https://issues.apache.org/jira/browse/DRILL-6922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva updated DRILL-6922: Description: Option `exec.return_result_set_for_ddl` is shown on Web UI's Profiles even when it was not set explicitly. The issue is because the option is being set on query level internally. *For documentation* Option `exec.return_result_set_for_ddl` was renamed to `exec.query.return_result_set_for_ddl`. was:Option `exec.return_result_set_for_ddl` is shown on Web UI's Profiles even when it was not set explicitly. The issue is because the option is being set on query level internally. > QUERY-level options are shown on Profiles tab > - > > Key: DRILL-6922 > URL: https://issues.apache.org/jira/browse/DRILL-6922 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Bohdan Kazydub >Assignee: Arina Ielchiieva >Priority: Blocker > Labels: doc-impacting > Fix For: 1.15.0 > > > Option `exec.return_result_set_for_ddl` is shown on Web UI's Profiles even > when it was not set explicitly. The issue is because the option is being set > on query level internally. > *For documentation* > Option `exec.return_result_set_for_ddl` was renamed to > `exec.query.return_result_set_for_ddl`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-6922) QUERY-level options are shown on Profiles tab
[ https://issues.apache.org/jira/browse/DRILL-6922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva updated DRILL-6922: Labels: doc-impacting (was: doc-im) > QUERY-level options are shown on Profiles tab > - > > Key: DRILL-6922 > URL: https://issues.apache.org/jira/browse/DRILL-6922 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Bohdan Kazydub >Assignee: Arina Ielchiieva >Priority: Blocker > Labels: doc-impacting > Fix For: 1.15.0 > > > Option `exec.return_result_set_for_ddl` is shown on Web UI's Profiles even > when it was not set explicitly. The issue is because the option is being set > on query level internally. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-6922) QUERY-level options are shown on Profiles tab
[ https://issues.apache.org/jira/browse/DRILL-6922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva updated DRILL-6922: Labels: doc-im (was: ) > QUERY-level options are shown on Profiles tab > - > > Key: DRILL-6922 > URL: https://issues.apache.org/jira/browse/DRILL-6922 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Bohdan Kazydub >Assignee: Arina Ielchiieva >Priority: Blocker > Labels: doc-impacting > Fix For: 1.15.0 > > > Option `exec.return_result_set_for_ddl` is shown on Web UI's Profiles even > when it was not set explicitly. The issue is because the option is being set > on query level internally. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DRILL-6913) Excessive error output
[
https://issues.apache.org/jira/browse/DRILL-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728354#comment-16728354
]
Anton Gozhiy commented on DRILL-6913:
-
Verified with Drill version 1.15.0-SNAPSHOT (commit
af3977a8e6ea2c66a585312bf64463a3d3bd9a6c)
Cases checked:
- the cases from the issue description
- verbose true/false
- multiline queries
- non-Calcite errors just in case
- embedded/distributed mode
> Excessive error output
> --
>
> Key: DRILL-6913
> URL: https://issues.apache.org/jira/browse/DRILL-6913
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Assignee: Arina Ielchiieva
>Priority: Blocker
> Labels: ready-to-commit
> Fix For: 1.15.0
>
>
> There are redundant and duplicate error messages in query outputs in case of
> some mistake in query syntax or in case of any other error from Calcite:
> {code:java}
> 0: jdbc:drill:zk=local> select * from dfs.`tpch/nation.parquet`;
> 19:23:09.335 [23e6d301-9bf4-2d4d-69e4-335a3674fd53:foreman] ERROR
> o.a.calcite.runtime.CalciteException -
> org.apache.calcite.sql.validate.SqlValidatorException: Object
> 'tpch/nation.parquet' not found within 'dfs'
> 19:23:09.336 [23e6d301-9bf4-2d4d-69e4-335a3674fd53:foreman] ERROR
> o.a.calcite.runtime.CalciteException -
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 15 to
> line 1, column 17: Object 'tpch/nation.parquet' not found within 'dfs'
> 19:23:09.411 [23e6d301-9bf4-2d4d-69e4-335a3674fd53:foreman] ERROR
> o.a.calcite.runtime.CalciteException -
> org.apache.calcite.sql.validate.SqlValidatorException: Object
> 'tpch/nation.parquet' not found within 'dfs'
> 19:23:09.411 [23e6d301-9bf4-2d4d-69e4-335a3674fd53:foreman] ERROR
> o.a.calcite.runtime.CalciteException -
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 15 to
> line 1, column 17: Object 'tpch/nation.parquet' not found within 'dfs'
> 19:23:09.432 [Client-1] ERROR o.a.calcite.runtime.CalciteException -
> org.apache.calcite.sql.validate.SqlValidatorException: Object
> 'tpch/nation.parquet' not found within 'dfs'
> 19:23:09.432 [Client-1] ERROR o.a.calcite.runtime.CalciteException -
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 15 to
> line 1, column 17: Object 'tpch/nation.parquet' not found within 'dfs':
> Object 'tpch/nation.parquet' not found within 'dfs'
> Error: VALIDATION ERROR: From line 1, column 15 to line 1, column 17: Object
> 'tpch/nation.parquet' not found within 'dfs'
> [Error Id: e3b6b9f6-1e8c-468f-954f-41b57defcf6a on vitalii-pc:31010]
> (state=,code=0)
> {code}
> {code:java}
> 0: jdbc:drill:zk=local> slect * from cp.`tpch/nation.parquet` limit 1;
> 20:40:27.783 [23e6c0e4-6dd7-2f72-12dc-abdb9f2f7634:foreman] ERROR
> o.a.calcite.runtime.CalciteException -
> org.apache.calcite.runtime.CalciteException: Non-query expression encountered
> in illegal context
> 20:40:27.783 [23e6c0e4-6dd7-2f72-12dc-abdb9f2f7634:foreman] ERROR
> o.a.calcite.runtime.CalciteException -
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 1 to
> line 1, column 5: Non-query expression encountered in illegal context
> 20:40:27.787 [Client-1] ERROR o.a.calcite.runtime.CalciteException -
> org.apache.calcite.runtime.CalciteException: Non-query expression encountered
> in illegal context
> Error: PARSE ERROR: Non-query expression encountered in illegal context
> SQL Query slect * from cp.`tpch/nation.parquet` limit 1
> ^
> [Error Id: c1bf1800-6b70-420b-b95c-907d11889a6f on vitalii-pc:31010]
> (state=,code=0)
> 0: jdbc:drill:zk=local>
> {code}
> Errors from drill code are fine:
> {code}
> 0: jdbc:drill:zk=local> select count(4,5) from cp.`tpch/nation.parquet` limit
> 1;
> Error: SYSTEM ERROR: SchemaChangeException: Failure while materializing
> expression.
> Error in expression at index -1. Error: Missing function implementation:
> [count(INT-REQUIRED, INT-REQUIRED)]. Full expression: --UNKNOWN EXPRESSION--.
> Fragment 0:0
> Please, refer to logs for more information.
> [Error Id: de0abc5a-cda9-4ac7-b99f-58f0ef0c7a67 on vitalii-pc:31010]
> (state=,code=0)
> {code}
> In drill Web UI the output is fine for all above cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (DRILL-6913) Excessive error output
[
https://issues.apache.org/jira/browse/DRILL-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Gozhiy closed DRILL-6913.
---
> Excessive error output
> --
>
> Key: DRILL-6913
> URL: https://issues.apache.org/jira/browse/DRILL-6913
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Assignee: Arina Ielchiieva
>Priority: Blocker
> Labels: ready-to-commit
> Fix For: 1.15.0
>
>
> There are redundant and duplicate error messages in query outputs in case of
> some mistake in query syntax or in case of any other error from Calcite:
> {code:java}
> 0: jdbc:drill:zk=local> select * from dfs.`tpch/nation.parquet`;
> 19:23:09.335 [23e6d301-9bf4-2d4d-69e4-335a3674fd53:foreman] ERROR
> o.a.calcite.runtime.CalciteException -
> org.apache.calcite.sql.validate.SqlValidatorException: Object
> 'tpch/nation.parquet' not found within 'dfs'
> 19:23:09.336 [23e6d301-9bf4-2d4d-69e4-335a3674fd53:foreman] ERROR
> o.a.calcite.runtime.CalciteException -
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 15 to
> line 1, column 17: Object 'tpch/nation.parquet' not found within 'dfs'
> 19:23:09.411 [23e6d301-9bf4-2d4d-69e4-335a3674fd53:foreman] ERROR
> o.a.calcite.runtime.CalciteException -
> org.apache.calcite.sql.validate.SqlValidatorException: Object
> 'tpch/nation.parquet' not found within 'dfs'
> 19:23:09.411 [23e6d301-9bf4-2d4d-69e4-335a3674fd53:foreman] ERROR
> o.a.calcite.runtime.CalciteException -
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 15 to
> line 1, column 17: Object 'tpch/nation.parquet' not found within 'dfs'
> 19:23:09.432 [Client-1] ERROR o.a.calcite.runtime.CalciteException -
> org.apache.calcite.sql.validate.SqlValidatorException: Object
> 'tpch/nation.parquet' not found within 'dfs'
> 19:23:09.432 [Client-1] ERROR o.a.calcite.runtime.CalciteException -
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 15 to
> line 1, column 17: Object 'tpch/nation.parquet' not found within 'dfs':
> Object 'tpch/nation.parquet' not found within 'dfs'
> Error: VALIDATION ERROR: From line 1, column 15 to line 1, column 17: Object
> 'tpch/nation.parquet' not found within 'dfs'
> [Error Id: e3b6b9f6-1e8c-468f-954f-41b57defcf6a on vitalii-pc:31010]
> (state=,code=0)
> {code}
> {code:java}
> 0: jdbc:drill:zk=local> slect * from cp.`tpch/nation.parquet` limit 1;
> 20:40:27.783 [23e6c0e4-6dd7-2f72-12dc-abdb9f2f7634:foreman] ERROR
> o.a.calcite.runtime.CalciteException -
> org.apache.calcite.runtime.CalciteException: Non-query expression encountered
> in illegal context
> 20:40:27.783 [23e6c0e4-6dd7-2f72-12dc-abdb9f2f7634:foreman] ERROR
> o.a.calcite.runtime.CalciteException -
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 1 to
> line 1, column 5: Non-query expression encountered in illegal context
> 20:40:27.787 [Client-1] ERROR o.a.calcite.runtime.CalciteException -
> org.apache.calcite.runtime.CalciteException: Non-query expression encountered
> in illegal context
> Error: PARSE ERROR: Non-query expression encountered in illegal context
> SQL Query slect * from cp.`tpch/nation.parquet` limit 1
> ^
> [Error Id: c1bf1800-6b70-420b-b95c-907d11889a6f on vitalii-pc:31010]
> (state=,code=0)
> 0: jdbc:drill:zk=local>
> {code}
> Errors from drill code are fine:
> {code}
> 0: jdbc:drill:zk=local> select count(4,5) from cp.`tpch/nation.parquet` limit
> 1;
> Error: SYSTEM ERROR: SchemaChangeException: Failure while materializing
> expression.
> Error in expression at index -1. Error: Missing function implementation:
> [count(INT-REQUIRED, INT-REQUIRED)]. Full expression: --UNKNOWN EXPRESSION--.
> Fragment 0:0
> Please, refer to logs for more information.
> [Error Id: de0abc5a-cda9-4ac7-b99f-58f0ef0c7a67 on vitalii-pc:31010]
> (state=,code=0)
> {code}
> In drill Web UI the output is fine for all above cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DRILL-6919) Error: cannot find symbol in class ServerSocketUtil
[
https://issues.apache.org/jira/browse/DRILL-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728332#comment-16728332
]
Denys Ordynskiy commented on DRILL-6919:
Successfully tested with mapr profile.
> Error: cannot find symbol in class ServerSocketUtil
> ---
>
> Key: DRILL-6919
> URL: https://issues.apache.org/jira/browse/DRILL-6919
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Denys Ordynskiy
>Assignee: Volodymyr Vysotskyi
>Priority: Blocker
> Labels: ready-to-commit
> Fix For: 1.15.0
>
>
> Compilation error when building Drill with mapr profile:
> {color:#d04437}[ERROR]
> /home/mapr/git_repo/drill/exec/java-exec/src/test/java/org/apache/drill/test/TestGracefulShutdown.java:[24,28]
> error: cannot find symbol
> symbol: class ServerSocketUtil
> location: package org.apache.hadoop.net{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6925) Unable to generate Protobuf
[
https://issues.apache.org/jira/browse/DRILL-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-6925:
Labels: ready-to-commit (was: )
> Unable to generate Protobuf
> ---
>
> Key: DRILL-6925
> URL: https://issues.apache.org/jira/browse/DRILL-6925
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Arina Ielchiieva
>Assignee: Vitalii Diravka
>Priority: Major
> Labels: ready-to-commit
> Fix For: 1.15.0
>
>
> When generating protocol buffers from protocol dir using {{mvn clean
> process-sources -P proto-compile}} the following error occurs:
> {noformat}
> [ERROR] Failed to execute goal com.mycila:license-maven-plugin:3.0:format
> (proto-format) on project drill-protocol: Execution proto-format of goal
> com.mycila:license-maven-plugin:3.0:format failed: Cannot read header
> document header. Cause: Resource header not found in file system, classpath
> or URL: no protocol: header -> [Help 1]
> [ERROR]
> {noformat}
> Regression after DRILL-6895.
> Also need to check C++ protobuf generation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (DRILL-4226) TestExtendedTypes#checkReadWriteExtended fails when the time zone is ahead of UTC
[
https://issues.apache.org/jira/browse/DRILL-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Vysotskyi resolved DRILL-4226.
Resolution: Fixed
Fix Version/s: 1.12.0
Fixed in the scope of DRILL-5717.
> TestExtendedTypes#checkReadWriteExtended fails when the time zone is ahead of
> UTC
> -
>
> Key: DRILL-4226
> URL: https://issues.apache.org/jira/browse/DRILL-4226
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Data Types
>Affects Versions: 1.4.0
> Environment: Mac OS X 10.10.5
>Reporter: Akihiko Kusanagi
>Priority: Major
> Fix For: 1.12.0
>
>
> Set the time zone to Asia/Tokyo on Mac OS X:
> {noformat}
> $ sudo systemsetup -gettimezone
> Time Zone: Asia/Tokyo
> {noformat}
> TestExtendedTypes#checkReadWriteExtended fails with the following output:
> {noformat}
> Running
> org.apache.drill.exec.vector.complex.writer.TestExtendedTypes#checkReadWriteExtended
> ...
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 6.17 sec <<<
> FAILURE! - in org.apache.drill.exec.vector.complex.writer.TestExtendedTypes
> checkReadWriteExtended(org.apache.drill.exec.vector.complex.writer.TestExtendedTypes)
> Time elapsed: 0.403 sec <<< FAILURE!
> org.junit.ComparisonFailure: expected:<...ateDay" : "1997-07-1[6"
> },
> "drill_timestamp" : {
> "$date" : "2009-02-23T08:00:00.000Z"
> },
> "time" : {
> "$time" : "19:20:30.450Z"
> },
> "interval" : {
> "$interval" : "PT26.400S"
> },
> "integer" : {
> "$numberLong" : 4
> },
> "inner" : {
> "bin" : {
> "$binary" : "ZHJpbGw="
> },
> "drill_date" : {
> "$dateDay" : "1997-07-16]"
> },
> "drill_...> but was:<...ateDay" : "1997-07-1[5"
> },
> "drill_timestamp" : {
> "$date" : "2009-02-23T08:00:00.000Z"
> },
> "time" : {
> "$time" : "19:20:30.450Z"
> },
> "interval" : {
> "$interval" : "PT26.400S"
> },
> "integer" : {
> "$numberLong" : 4
> },
> "inner" : {
> "bin" : {
> "$binary" : "ZHJpbGw="
> },
> "drill_date" : {
> "$dateDay" : "1997-07-15]"
> },
> "drill_...>
> at
> org.apache.drill.exec.vector.complex.writer.TestExtendedTypes.checkReadWriteExtended(TestExtendedTypes.java:60)
> ...
> Failed tests:
> TestExtendedTypes.checkReadWriteExtended:60 expected:<...ateDay" :
> "1997-07-1[6"
> },
> "drill_timestamp" : {
> "$date" : "2009-02-23T08:00:00.000Z"
> },
> "time" : {
> "$time" : "19:20:30.450Z"
> },
> "interval" : {
> "$interval" : "PT26.400S"
> },
> "integer" : {
> "$numberLong" : 4
> },
> "inner" : {
> "bin" : {
> "$binary" : "ZHJpbGw="
> },
> "drill_date" : {
> "$dateDay" : "1997-07-16]"
> },
> "drill_...> but was:<...ateDay" : "1997-07-1[5"
> },
> "drill_timestamp" : {
> "$date" : "2009-02-23T08:00:00.000Z"
> },
> "time" : {
> "$time" : "19:20:30.450Z"
> },
> "interval" : {
> "$interval" : "PT26.400S"
> },
> "integer" : {
> "$numberLong" : 4
> },
> "inner" : {
> "bin" : {
> "$binary" : "ZHJpbGw="
> },
> "drill_date" : {
> "$dateDay" : "1997-07-15]"
> },
> "drill_...>
> {noformat}
> Test queries are like this:
> {noformat}
> ALTER SESSION SET `store.format` = 'json'
> ALTER SESSION SET `store.json.extended_types` = true
> create table dfs_test.tmp.`TestExtendedTypes/newjson` as select * from
> dfs.`${WORKING_PATH}/src/test/resources/vector/complex/extended.json`
> {noformat}
> It seems that Drill parses '1997-07-16' as a UTC date but writes it as a
> local date. If the system time zone is ahead of UTC, it will be changed to
> '1997-07-15'. I understand this is the current limitation, but the test code
> or configuration should be aware of it.
> https://drill.apache.org/docs/data-type-conversion/#time-zone-limitation
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (DRILL-5141) Difference in output date format on sqlline vs Drill's Web UI
[
https://issues.apache.org/jira/browse/DRILL-5141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Vysotskyi resolved DRILL-5141.
Resolution: Fixed
Fix Version/s: 1.15.0
> Difference in output date format on sqlline vs Drill's Web UI
> -
>
> Key: DRILL-5141
> URL: https://issues.apache.org/jira/browse/DRILL-5141
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.9.0
>Reporter: Khurram Faraaz
>Priority: Minor
> Fix For: 1.15.0
>
>
> Difference in output date format on sqlline vs Drill's Web UI
> Drill 1.9.0 git commit ID : 4c1b420b
> From sqlline prompt
> {noformat}
> 0: jdbc:drill:schema=dfs.tmp> SELECT cast('2016/09/22' as date) FROM
> (VALUES(1));
> +-+
> | EXPR$0|
> +-+
> | 2016-09-22 |
> +-+
> 1 row selected (0.474 seconds)
> {noformat}
> The same query returns a date in a different output format on the web UI
> {noformat}
> 2016-09-22T00:00:00.000Z
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DRILL-5141) Difference in output date format on sqlline vs Drill's Web UI
[
https://issues.apache.org/jira/browse/DRILL-5141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728291#comment-16728291
]
Volodymyr Vysotskyi commented on DRILL-5141:
[~khfaraaz], looks like this issue was resolved. Both sqlline and web-UI
returns \{{2016-09-22}}.
> Difference in output date format on sqlline vs Drill's Web UI
> -
>
> Key: DRILL-5141
> URL: https://issues.apache.org/jira/browse/DRILL-5141
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.9.0
>Reporter: Khurram Faraaz
>Priority: Minor
>
> Difference in output date format on sqlline vs Drill's Web UI
> Drill 1.9.0 git commit ID : 4c1b420b
> From sqlline prompt
> {noformat}
> 0: jdbc:drill:schema=dfs.tmp> SELECT cast('2016/09/22' as date) FROM
> (VALUES(1));
> +-+
> | EXPR$0|
> +-+
> | 2016-09-22 |
> +-+
> 1 row selected (0.474 seconds)
> {noformat}
> The same query returns a date in a different output format on the web UI
> {noformat}
> 2016-09-22T00:00:00.000Z
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (DRILL-5141) Difference in output date format on sqlline vs Drill's Web UI
[
https://issues.apache.org/jira/browse/DRILL-5141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728291#comment-16728291
]
Volodymyr Vysotskyi edited comment on DRILL-5141 at 12/24/18 9:25 AM:
--
[~khfaraaz], looks like this issue was resolved. Both sqlline and web-UI return
{{2016-09-22}}.
was (Author: vvysotskyi):
[~khfaraaz], looks like this issue was resolved. Both sqlline and web-UI
returns \{{2016-09-22}}.
> Difference in output date format on sqlline vs Drill's Web UI
> -
>
> Key: DRILL-5141
> URL: https://issues.apache.org/jira/browse/DRILL-5141
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.9.0
>Reporter: Khurram Faraaz
>Priority: Minor
>
> Difference in output date format on sqlline vs Drill's Web UI
> Drill 1.9.0 git commit ID : 4c1b420b
> From sqlline prompt
> {noformat}
> 0: jdbc:drill:schema=dfs.tmp> SELECT cast('2016/09/22' as date) FROM
> (VALUES(1));
> +-+
> | EXPR$0|
> +-+
> | 2016-09-22 |
> +-+
> 1 row selected (0.474 seconds)
> {noformat}
> The same query returns a date in a different output format on the web UI
> {noformat}
> 2016-09-22T00:00:00.000Z
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (DRILL-4582) TestCastFunctions#testToDateForTimeStamp returns error by timezone difference
[
https://issues.apache.org/jira/browse/DRILL-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Vysotskyi resolved DRILL-4582.
Resolution: Fixed
Fix Version/s: 1.12.0
Fixed in the scope of DRILL-5717.
> TestCastFunctions#testToDateForTimeStamp returns error by timezone difference
> -
>
> Key: DRILL-4582
> URL: https://issues.apache.org/jira/browse/DRILL-4582
> Project: Apache Drill
> Issue Type: Bug
> Components: Functions - Drill
>Affects Versions: 1.7.0
>Reporter: Jihun Kang
>Priority: Minor
> Fix For: 1.12.0
>
>
> When running drill tests on a machine with positive offsets of timezone,
> following error is created. This error comes from the joda datetime, because
> joda datetime create an object with default timezone.
> {noformat}
> Running org.apache.drill.exec.fn.impl.TestCastFunctions#testToDateForTimeStamp
> java.lang.Exception: at position 0 column '`col`' mismatched values,
> expected: 1969-12-31T00:00:00.000+09:00(DateTime) but received
> 1970-01-01T00:00:00.000+09:00(DateTime)
> Expected Records near verification failure:
> Record Number: 0 { `col` : 1969-12-31T00:00:00.000+09:00, }
> Actual Records near verification failure:
> Record Number: 0 { `col` : 1970-01-01T00:00:00.000+09:00, }
> For query: select to_date(to_timestamp(-1)) as col
> from (values(1))
> at
> org.apache.drill.DrillTestWrapper.compareMergedOnHeapVectors(DrillTestWrapper.java:436)
> at
> org.apache.drill.DrillTestWrapper.compareOrderedResults(DrillTestWrapper.java:390)
> at org.apache.drill.DrillTestWrapper.run(DrillTestWrapper.java:126)
> at
> org.apache.drill.exec.fn.impl.TestCastFunctions.testToDateForTimeStamp(TestCastFunctions.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:606)
> Caused by: java.lang.Exception: at position 0 column '`col`' mismatched
> values, expected: 1969-12-31T00:00:00.000+09:00(DateTime) but received
> 1970-01-01T00:00:00.000+09:00(DateTime)
> Expected Records near verification failure:
> Record Number: 0 { `col` : 1969-12-31T00:00:00.000+09:00, }
> Actual Records near verification failure:
> Record Number: 0 { `col` : 1970-01-01T00:00:00.000+09:00, }
> at
> org.apache.drill.DrillTestWrapper.compareMergedVectors(DrillTestWrapper.java:174)
> at
> org.apache.drill.DrillTestWrapper.compareMergedOnHeapVectors(DrillTestWrapper.java:434)
> ... 7 more
> Caused by: java.lang.Exception: at position 0 column '`col`' mismatched
> values, expected: 1969-12-31T00:00:00.000+09:00(DateTime) but received
> 1970-01-01T00:00:00.000+09:00(DateTime)
> at
> org.apache.drill.DrillTestWrapper.compareValuesErrorOnMismatch(DrillTestWrapper.java:552)
> at
> org.apache.drill.DrillTestWrapper.compareMergedVectors(DrillTestWrapper.java:172)
> ... 8 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (DRILL-5606) Some tests fail after creating a fresh clone
[
https://issues.apache.org/jira/browse/DRILL-5606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Vysotskyi resolved DRILL-5606.
Resolution: Fixed
Fixed in the scope of DRILL-5717.
> Some tests fail after creating a fresh clone
>
>
> Key: DRILL-5606
> URL: https://issues.apache.org/jira/browse/DRILL-5606
> Project: Apache Drill
> Issue Type: Bug
> Components: Tools, Build Test
>Affects Versions: 1.9.0, 1.11.0
> Environment: {noformat}
> $ uname -a
> Linux mg-mate 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017
> x86_64 x86_64 x86_64 GNU/Linux
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 16.04.2 LTS
> Release: 16.04
> Codename: xenial
> $ java -version
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-0ubuntu1.16.04.2-b11)
> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
> {noformat}
> Environment variables JAVA_HOME, JRE_HOME, JDK_HOME aren't configured. Java
> executable is found as the PATH environment variables links to it. I can
> provide more details if needed.
>Reporter: Muhammad Gelbana
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: failing_tests.tar.gz, full_log.txt.tar.gz,
> surefire-reports.tar.gz
>
>
> I cloned Drill from Github using this url:
> [https://github.com/apache/drill.git] and I didn't change the branch
> afterwards, so I'm using *master*.
> Afterwards, I ran the following command
> {noformat}
> mvn clean install
> {noformat}
> I attached the full log but here is a snippet indicating the failing tests:
> {noformat}
> Failed tests:
> TestExtendedTypes.checkReadWriteExtended:60 expected:<...ateDay" :
> "1997-07-1[6"
> },
> "drill_timestamp" : {
> "$date" : "2009-02-23T08:00:00.000Z"
> },
> "time" : {
> "$time" : "19:20:30.450Z"
> },
> "interval" : {
> "$interval" : "PT26.400S"
> },
> "integer" : {
> "$numberLong" : 4
> },
> "inner" : {
> "bin" : {
> "$binary" : "ZHJpbGw="
> },
> "drill_date" : {
> "$dateDay" : "1997-07-16]"
> },
> "drill_...> but was:<...ateDay" : "1997-07-1[5"
> },
> "drill_timestamp" : {
> "$date" : "2009-02-23T08:00:00.000Z"
> },
> "time" : {
> "$time" : "19:20:30.450Z"
> },
> "interval" : {
> "$interval" : "PT26.400S"
> },
> "integer" : {
> "$numberLong" : 4
> },
> "inner" : {
> "bin" : {
> "$binary" : "ZHJpbGw="
> },
> "drill_date" : {
> "$dateDay" : "1997-07-15]"
> },
> "drill_...>
> Tests in error:
> TestCastFunctions.testToDateForTimeStamp:79 » at position 0 column '`col`'
> mi...
> TestNewDateFunctions.testIsDate:61 » After matching 0 records, did not
> find e...
> Tests run: 2128, Failures: 1, Errors: 2, Skipped: 139
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Drill Root POM .. SUCCESS [ 19.805
> s]
> [INFO] tools/Parent Pom ... SUCCESS [ 0.605
> s]
> [INFO] tools/freemarker codegen tooling ... SUCCESS [ 7.077
> s]
> [INFO] Drill Protocol . SUCCESS [ 7.959
> s]
> [INFO] Common (Logical Plan, Base expressions) SUCCESS [ 7.734
> s]
> [INFO] Logical Plan, Base expressions . SUCCESS [ 8.099
> s]
> [INFO] exec/Parent Pom SUCCESS [ 0.575
> s]
> [INFO] exec/memory/Parent Pom . SUCCESS [ 0.513
> s]
> [INFO] exec/memory/base ... SUCCESS [ 4.666
> s]
> [INFO] exec/rpc ... SUCCESS [ 2.684
> s]
> [INFO] exec/Vectors ... SUCCESS [01:11
> min]
> [INFO] contrib/Parent Pom . SUCCESS [ 0.547
> s]
> [INFO] contrib/data/Parent Pom SUCCESS [ 0.496
> s]
> [INFO] contrib/data/tpch-sample-data .. SUCCESS [ 2.698
> s]
> [INFO] exec/Java Execution Engine . FAILURE [19:09
> min]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-5606) Some tests fail after creating a fresh clone
[
https://issues.apache.org/jira/browse/DRILL-5606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Vysotskyi updated DRILL-5606:
---
Fix Version/s: 1.12.0
> Some tests fail after creating a fresh clone
>
>
> Key: DRILL-5606
> URL: https://issues.apache.org/jira/browse/DRILL-5606
> Project: Apache Drill
> Issue Type: Bug
> Components: Tools, Build Test
>Affects Versions: 1.9.0, 1.11.0
> Environment: {noformat}
> $ uname -a
> Linux mg-mate 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017
> x86_64 x86_64 x86_64 GNU/Linux
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 16.04.2 LTS
> Release: 16.04
> Codename: xenial
> $ java -version
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-0ubuntu1.16.04.2-b11)
> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
> {noformat}
> Environment variables JAVA_HOME, JRE_HOME, JDK_HOME aren't configured. Java
> executable is found as the PATH environment variables links to it. I can
> provide more details if needed.
>Reporter: Muhammad Gelbana
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: failing_tests.tar.gz, full_log.txt.tar.gz,
> surefire-reports.tar.gz
>
>
> I cloned Drill from Github using this url:
> [https://github.com/apache/drill.git] and I didn't change the branch
> afterwards, so I'm using *master*.
> Afterwards, I ran the following command
> {noformat}
> mvn clean install
> {noformat}
> I attached the full log but here is a snippet indicating the failing tests:
> {noformat}
> Failed tests:
> TestExtendedTypes.checkReadWriteExtended:60 expected:<...ateDay" :
> "1997-07-1[6"
> },
> "drill_timestamp" : {
> "$date" : "2009-02-23T08:00:00.000Z"
> },
> "time" : {
> "$time" : "19:20:30.450Z"
> },
> "interval" : {
> "$interval" : "PT26.400S"
> },
> "integer" : {
> "$numberLong" : 4
> },
> "inner" : {
> "bin" : {
> "$binary" : "ZHJpbGw="
> },
> "drill_date" : {
> "$dateDay" : "1997-07-16]"
> },
> "drill_...> but was:<...ateDay" : "1997-07-1[5"
> },
> "drill_timestamp" : {
> "$date" : "2009-02-23T08:00:00.000Z"
> },
> "time" : {
> "$time" : "19:20:30.450Z"
> },
> "interval" : {
> "$interval" : "PT26.400S"
> },
> "integer" : {
> "$numberLong" : 4
> },
> "inner" : {
> "bin" : {
> "$binary" : "ZHJpbGw="
> },
> "drill_date" : {
> "$dateDay" : "1997-07-15]"
> },
> "drill_...>
> Tests in error:
> TestCastFunctions.testToDateForTimeStamp:79 » at position 0 column '`col`'
> mi...
> TestNewDateFunctions.testIsDate:61 » After matching 0 records, did not
> find e...
> Tests run: 2128, Failures: 1, Errors: 2, Skipped: 139
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Drill Root POM .. SUCCESS [ 19.805
> s]
> [INFO] tools/Parent Pom ... SUCCESS [ 0.605
> s]
> [INFO] tools/freemarker codegen tooling ... SUCCESS [ 7.077
> s]
> [INFO] Drill Protocol . SUCCESS [ 7.959
> s]
> [INFO] Common (Logical Plan, Base expressions) SUCCESS [ 7.734
> s]
> [INFO] Logical Plan, Base expressions . SUCCESS [ 8.099
> s]
> [INFO] exec/Parent Pom SUCCESS [ 0.575
> s]
> [INFO] exec/memory/Parent Pom . SUCCESS [ 0.513
> s]
> [INFO] exec/memory/base ... SUCCESS [ 4.666
> s]
> [INFO] exec/rpc ... SUCCESS [ 2.684
> s]
> [INFO] exec/Vectors ... SUCCESS [01:11
> min]
> [INFO] contrib/Parent Pom . SUCCESS [ 0.547
> s]
> [INFO] contrib/data/Parent Pom SUCCESS [ 0.496
> s]
> [INFO] contrib/data/tpch-sample-data .. SUCCESS [ 2.698
> s]
> [INFO] exec/Java Execution Engine . FAILURE [19:09
> min]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
