[jira] [Commented] (DRILL-6982) Affected rows count is not returned by Drill if return_result_set_for_ddl is false

2019-01-18 Thread Kunal Khatua (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746884#comment-16746884
 ] 

Kunal Khatua commented on DRILL-6982:
-

I'm a little confused. Is this a documentation bug?
I would think setting the flag to {{false}} should +not+ return the row count.
 [~bbevens] ?

> Affected rows count is not returned by Drill if return_result_set_for_ddl is 
> false
> --
>
> Key: DRILL-6982
> URL: https://issues.apache.org/jira/browse/DRILL-6982
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Anton Gozhiy
>Priority: Major
>
> *Prerequisites:*
> {code:sql}
> set `exec.query.return_result_set_for_ddl`= false;
> {code}
> *Query:*
> {code:sql}
> create table dfs.tmp.`nation as select * from cp.`tpch/nation.parquet`;
> {code}
> *Expected result:*
> Drill should return the number of affected rows (25 in this case)
> *Actual Result:*
> The table was created, but affected rows count wasn't returned:
> {noformat}
> No rows affected (1.755 seconds)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DRILL-6938) SQL get the wrong result after hashjoin and hashagg disabled

2019-01-18 Thread Pritesh Maker (JIRA)


 [ 
https://issues.apache.org/jira/browse/DRILL-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pritesh Maker updated DRILL-6938:
-
Fix Version/s: 1.16.0

> SQL get the wrong result after hashjoin and hashagg disabled
> 
>
> Key: DRILL-6938
> URL: https://issues.apache.org/jira/browse/DRILL-6938
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Dony Dong
>Assignee: Boaz Ben-Zvi
>Priority: Critical
> Fix For: 1.16.0
>
>
> Hi Team
> After we disable hashjoin and hashagg to fix out of memory issue, we got the 
> wrong result.
> With these two parameters enabled, we will get 8 rows. After we disable them, 
> it only return 3 rows. It seems some MEM_ID had exclude before group or some 
> other step.
> select b.MEM_ID,count(distinct b.DEP_NO)
> from dfs.test.emp b
> where b.DEP_NO<>'-'
> and b.MEM_ID in ('68','412','852','117','657','816','135','751')
> and b.HIRE_DATE>'2014-06-01'
> group by b.MEM_ID
> order by 1;



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DRILL-6981) command line option to choose/force drill-override.conf

2019-01-18 Thread Kunal Khatua (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746684#comment-16746684
 ] 

Kunal Khatua commented on DRILL-6981:
-

[~benj641] your ask is valid, and [~Paul.Rogers]'s​ recommendation actually 
addresses that and more. For e.g., there are folks who might want other 
settings to be different and not just {{drill-override.conf}} . In short, 
everyone has a personal style of managing multiple configs. This ( {{--site}} ) 
seemed the most generic and appealing when implemented.

If you do intend to implement something like what you've suggested, it would be 
worth considering whether you want pass off multiple config files as well. It's 
mostly about fiddling with the order in which the files are placed in the 
classpath during startup.


> command line option to choose/force drill-override.conf 
> 
>
> Key: DRILL-6981
> URL: https://issues.apache.org/jira/browse/DRILL-6981
> Project: Apache Drill
>  Issue Type: Wish
>Affects Versions: 1.15.0
>Reporter: benj
>Priority: Minor
>
> It will be nice to have a command line option from sqlline to specify which 
> file to use to override instead of the natural drill-overide.conf.
> Example :
>  
> {code:java}
> ./sqlline --conf=../conf/another-drill-overide.conf
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (DRILL-6972) Error: Could not find or load main class sqlline.SqlLine

2019-01-18 Thread Kunal Khatua (JIRA)


 [ 
https://issues.apache.org/jira/browse/DRILL-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kunal Khatua resolved DRILL-6972.
-
Resolution: Works for Me

[~elenacampean] this worked for me with the latest Apache 1.15.0 release. 
I am on a Windows 10 64-bit machine.

Here is the console output captured:
{code}
C:\Users\kkhatua\Downloads\ttl_3month\apache-drill-1.15.0.tar\apache-drill-1.15.0>dir
 Volume in drive C is Windows
 Volume Serial Number is 6C77-5BE3

 Directory of 
C:\Users\kkhatua\Downloads\ttl_3month\apache-drill-1.15.0.tar\apache-drill-1.15.0

01/18/2019  01:19 PM  .
01/18/2019  01:19 PM  ..
01/18/2019  01:19 PM  bin
01/18/2019  01:19 PM  conf
12/24/2018  10:30 AM   941 git.properties
01/18/2019  01:19 PM  jars
12/24/2018  09:29 AM46,514 KEYS
12/24/2018  09:29 AM63,245 LICENSE
12/24/2018  09:29 AM   238 NOTICE
12/24/2018  09:29 AM 1,301 README.md
01/18/2019  01:19 PM  sample-data
   5 File(s)112,239 bytes
   6 Dir(s)  351,264,067,584 bytes free

C:\Users\kkhatua\Downloads\ttl_3month\apache-drill-1.15.0.tar\apache-drill-1.15.0>type
 git.properties
#Generated by Git-Commit-Id-Plugin
#Mon Dec 24 20:30:32 EET 2018
git.branch=8743e8f1e8d5bca4d67c94d07a8560ad356ff2b6
git.build.host=vitalii-pc
git.build.time=24.12.2018 @ 20\:30\:32 EET
git.build.user.email=vitalii.dira...@gmail.com
git.build.user.name=Vitalii Diravka
git.build.version=1.15.0
git.closest.tag.commit.count=0
git.closest.tag.name=drill-1.15.0
git.commit.id=8743e8f1e8d5bca4d67c94d07a8560ad356ff2b6
git.commit.id.abbrev=8743e8f
git.commit.id.describe=drill-1.15.0-0-g8743e8f
git.commit.id.describe-short=drill-1.15.0-0
git.commit.message.full=[maven-release-plugin] prepare release drill-1.15.0
git.commit.message.short=[maven-release-plugin] prepare release drill-1.15.0
git.commit.time=24.12.2018 @ 20\:09\:05 EET
git.commit.user.email=vitalii.dira...@gmail.com
git.commit.user.name=Vitalii Diravka
git.dirty=false
git.remote.origin.url=https\://github.com/apache/drill.git
git.tags=drill-1.15.0
git.total.commit.count=3407

C:\Users\kkhatua\Downloads\ttl_3month\apache-drill-1.15.0.tar\apache-drill-1.15.0>cd
 bin

C:\Users\kkhatua\Downloads\ttl_3month\apache-drill-1.15.0.tar\apache-drill-1.15.0\bin>sqlline
 -u "jdbc:drill:zk=local"
DRILL_ARGS - " -u jdbc:drill:zk=local"
HADOOP_HOME not detected...
HBASE_HOME not detected...
Calculating Drill classpath...
Exception in thread "main" java.lang.IllegalArgumentException: Bad history file 
syntax! The history file `C:\Users\kkhatua\sqlline\history` may be an older 
history: please remove it or use a different history file.
at 
org.jline.reader.impl.history.DefaultHistory.addHistoryLine(DefaultHistory.java:104)
at 
org.jline.reader.impl.history.DefaultHistory.lambda$load$0(DefaultHistory.java:86)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at 
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at 
java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
at 
org.jline.reader.impl.history.DefaultHistory.load(DefaultHistory.java:86)
at 
org.jline.reader.impl.history.DefaultHistory.attach(DefaultHistory.java:69)
at sqlline.SqlLine.getConsoleReader(SqlLine.java:614)
at sqlline.SqlLine.begin(SqlLine.java:510)
at sqlline.SqlLine.start(SqlLine.java:264)
at sqlline.SqlLine.main(SqlLine.java:195)

C:\Users\kkhatua\Downloads\ttl_3month\apache-drill-1.15.0.tar\apache-drill-1.15.0\bin>del
 C:\Users\kkhatua\sqlline\history

C:\Users\kkhatua\Downloads\ttl_3month\apache-drill-1.15.0.tar\apache-drill-1.15.0\bin>sqlline
 -u "jdbc:drill:zk=local"
DRILL_ARGS - " -u jdbc:drill:zk=local"
HADOOP_HOME not detected...
HBASE_HOME not detected...
Calculating Drill classpath...
Apache Drill 1.15.0
"Just Drill It."
0: jdbc:drill:zk=local> select * from sys.drillbits;
+-++---+++--+--+-+
|  hostname   | user_port  | control_port  | data_port  | http_port  | current  
| version  |  state  |
+-++---+++--+--+-+
| t470s-1196  | 31010  | 31011 | 31012  | 8047   | true 
| 1.15.0   | ONLINE  |
+-++---+++--+--+-+
1 row selected (2.941 seconds)
0: jdbc:drill:zk=local> !q
Closing: org.apache.drill.jdbc.impl.DrillConnectionImpl

{code}

> Error: Could not find or load main class sqlline.SqlLine
> 
>
> Key: DRILL-6972
> URL: https://issues.apache.org/jira/browse/DRILL-6972
> Project: Apache Drill

[jira] [Updated] (DRILL-6979) Add autofocus attribute to username on login page, and to query textbox on Query tab.

2019-01-18 Thread Kunal Khatua (JIRA)


 [ 
https://issues.apache.org/jira/browse/DRILL-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kunal Khatua updated DRILL-6979:

Labels: user-experience  (was: )

> Add autofocus attribute to username on login page, and to query textbox on 
> Query tab.
> -
>
> Key: DRILL-6979
> URL: https://issues.apache.org/jira/browse/DRILL-6979
> Project: Apache Drill
>  Issue Type: Improvement
>  Components: Web Server
>Affects Versions: 1.16.0
>Reporter: Khurram Faraaz
>Assignee: Khurram Faraaz
>Priority: Minor
>  Labels: user-experience
>
> Add autofocus attribute to username on login page, and to query textbox on 
> Query tab.
> The two text boxes that need the change are in these files
> ./exec/java-exec/src/main/resources/rest/query/query.ftl
> ./exec/java-exec/src/main/resources/rest/login.ftl



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DRILL-6974) SET/SHOW

2019-01-18 Thread Kunal Khatua (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746642#comment-16746642
 ] 

Kunal Khatua commented on DRILL-6974:
-

I believe the {{SHOW }} would be ambiguous since it is used with 
reserved keywords like {{DATABASES}} , etc

> SET/SHOW
> 
>
> Key: DRILL-6974
> URL: https://issues.apache.org/jira/browse/DRILL-6974
> Project: Apache Drill
>  Issue Type: Improvement
>  Components: SQL Parser
>Affects Versions: 1.15.0
>Reporter: benj
>Priority: Major
>
> It's currently possible to define options with the SQL command SET
> {code:java}
> ALTER SESSION SET `drill.exec.hashagg.fallback.enabled` = true;
> {code}
> But it's not possible to simply visualize the current value of one option 
> with SHOW, we have to query like
> {code:java}
> SELECT * FROM sys.options WHERE `name` = 
> 'drill.exec.hashagg.fallback.enabled';
> {code}
> Why not allow a simple
> {code:java}
> SHOW 'drill.exec.hashagg.fallback.enabled';
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DRILL-6978) typeOf drillTypeOf sqlTypeOf not work with generated tables

2019-01-18 Thread Kunal Khatua (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746640#comment-16746640
 ] 

Kunal Khatua commented on DRILL-6978:
-

[~benj641] Can you share this question on the dev mailing list?

> typeOf drillTypeOf sqlTypeOf not work with generated tables
> ---
>
> Key: DRILL-6978
> URL: https://issues.apache.org/jira/browse/DRILL-6978
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Functions - Drill
>Affects Versions: 1.15.0
>Reporter: benj
>Priority: Major
>
>  
> *TypeOf functions works when request on files but doesn't work on "generated" 
> data
> This works :
> {code:java}
> SELECT typeof(md5), drillTypeOf(md5), sqlTypeOf(md5) FROM 
> dfs.tmp.`mytable.csv` LIMIT 2;
> => (OK)
> +--+--++
> |  EXPR$0  |  EXPR$1  |   EXPR$2   |
> +--+--++
> | VARCHAR  | VARCHAR  | CHARACTER VARYING  |
> | VARCHAR  | VARCHAR  | CHARACTER VARYING  |
> +--+--++{code}
> But not :
>  
>  
> {code:java}
> SELECT typeOf(a) FROM (SELECT CAST (5 as int) AS a) x;
> => (NOK)
> Error: SYSTEM ERROR: IllegalArgumentException: Can not set 
> org.apache.drill.exec.vector.complex.reader.FieldReader field 
> org.apache.drill.exec.expr.fn.impl.UnionFunctions$GetType.input to 
> org.apache.drill.exec.expr.holders.IntHolder
> {code}
> And in a surprising way the next query works :
> {code:java}
> SELECT md5, typeof(t), drillTypeOf(t), sqlTypeOf(t) FROM ((SELECT 'foo' AS t 
> ) union (SELECT 'far' AS t)) x;
> => (OK)
> +---+--+--++
> |  md5  |  EXPR$1  |  EXPR$2  |   EXPR$3   |
> +---+--+--++
> | foo   | VARCHAR  | VARCHAR  | CHARACTER VARYING  |
> | bar   | VARCHAR  | VARCHAR  | CHARACTER VARYING  |
> +---+--+--++{code}
>  
>  
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DRILL-6963) create/aggregate/work with array

2019-01-18 Thread Kunal Khatua (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746629#comment-16746629
 ] 

Kunal Khatua commented on DRILL-6963:
-

[~benj641] do you have a reference of an existing system that does this? 
An example with a sample data in the description would help other committers 
provide feedback on the feasibility of the feature.

> create/aggregate/work with array
> 
>
> Key: DRILL-6963
> URL: https://issues.apache.org/jira/browse/DRILL-6963
> Project: Apache Drill
>  Issue Type: Wish
>  Components: Functions - Drill
>Reporter: benj
>Priority: Major
>
> * Add the possibility to build array (like : SELECT array[a1,a2,a3...]) - 
> ideally work with all types
>  * Add a default array_agg (like : SELECT col1, array_agg(col2), 
> array_agg(DISTINCT col2) FROM ... GROUP BY col1) ;  - ideally work with all 
> types
>  * Add function/facilities/operator to work with array



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DRILL-6970) Issue with LogRegex format plugin where drillbuf was overflowing

2019-01-18 Thread Kunal Khatua (JIRA)


 [ 
https://issues.apache.org/jira/browse/DRILL-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kunal Khatua updated DRILL-6970:

Fix Version/s: 1.16.0

> Issue with LogRegex format plugin where drillbuf was overflowing 
> -
>
> Key: DRILL-6970
> URL: https://issues.apache.org/jira/browse/DRILL-6970
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: jean-claude
>Priority: Major
> Fix For: 1.16.0
>
>
> The log format plugin does re-allocate the drillbuf when it fills up. You can 
> query small log files but larger ones will fail with this error:
> 0: jdbc:drill:zk=local> select * from dfs.root.`/prog/test.log`;
> Error: INTERNAL_ERROR ERROR: index: 32724, length: 108 (expected: range(0, 
> 32768))
> Fragment 0:0
> Please, refer to logs for more information.
>  
> I'm running drill-embeded. The log storage plugin is configured like so
> {code:java}
> "log": {
> "type": "logRegex",
> "regex": "(.+)",
> "extension": "log",
> "maxErrors": 10,
> "schema": [
> {
> "fieldName": "line"
> }
> ]
> },
> {code}
> The log files is very simple
> {code:java}
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> ...{code}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DRILL-6970) Issue with LogRegex format plugin where drillbuf was overflowing

2019-01-18 Thread Kunal Khatua (JIRA)


 [ 
https://issues.apache.org/jira/browse/DRILL-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kunal Khatua updated DRILL-6970:

Summary: Issue with LogRegex format plugin where drillbuf was overflowing   
(was: Issue with logregex format plugin where drillbuf was overflowing )

> Issue with LogRegex format plugin where drillbuf was overflowing 
> -
>
> Key: DRILL-6970
> URL: https://issues.apache.org/jira/browse/DRILL-6970
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: jean-claude
>Priority: Major
>
> The log format plugin does re-allocate the drillbuf when it fills up. You can 
> query small log files but larger ones will fail with this error:
> 0: jdbc:drill:zk=local> select * from dfs.root.`/prog/test.log`;
> Error: INTERNAL_ERROR ERROR: index: 32724, length: 108 (expected: range(0, 
> 32768))
> Fragment 0:0
> Please, refer to logs for more information.
>  
> I'm running drill-embeded. The log storage plugin is configured like so
> {code:java}
> "log": {
> "type": "logRegex",
> "regex": "(.+)",
> "extension": "log",
> "maxErrors": 10,
> "schema": [
> {
> "fieldName": "line"
> }
> ]
> },
> {code}
> The log files is very simple
> {code:java}
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> ...{code}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DRILL-6970) Issue with logregex format plugin where drillbuf was overflowing

2019-01-18 Thread Kunal Khatua (JIRA)


 [ 
https://issues.apache.org/jira/browse/DRILL-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kunal Khatua updated DRILL-6970:

Summary: Issue with logregex format plugin where drillbuf was overflowing   
(was: LogRegex format plugin)

> Issue with logregex format plugin where drillbuf was overflowing 
> -
>
> Key: DRILL-6970
> URL: https://issues.apache.org/jira/browse/DRILL-6970
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: jean-claude
>Priority: Major
>
> The log format plugin does re-allocate the drillbuf when it fills up. You can 
> query small log files but larger ones will fail with this error:
> 0: jdbc:drill:zk=local> select * from dfs.root.`/prog/test.log`;
> Error: INTERNAL_ERROR ERROR: index: 32724, length: 108 (expected: range(0, 
> 32768))
> Fragment 0:0
> Please, refer to logs for more information.
>  
> I'm running drill-embeded. The log storage plugin is configured like so
> {code:java}
> "log": {
> "type": "logRegex",
> "regex": "(.+)",
> "extension": "log",
> "maxErrors": 10,
> "schema": [
> {
> "fieldName": "line"
> }
> ]
> },
> {code}
> The log files is very simple
> {code:java}
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> jdsaljfldaksjfldsajfldasjflkjdsfldsjfljsdalfk
> ...{code}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DRILL-6968) pattern matching and regexp facilities

2019-01-18 Thread Kunal Khatua (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746632#comment-16746632
 ] 

Kunal Khatua commented on DRILL-6968:
-

[~benj641] this could be implemented as a UDF. Do you want to give it a try?
[~cgivre] and [~paul-rogers] have a book recently published that touches upon 
writing UDFs in reasonable amount of detail and can help on the dev mailing 
list as well.

> pattern matching and regexp facilities
> --
>
> Key: DRILL-6968
> URL: https://issues.apache.org/jira/browse/DRILL-6968
> Project: Apache Drill
>  Issue Type: Wish
>  Components: Functions - Drill
>Affects Versions: 1.15.0
>Reporter: benj
>Priority: Major
>
> Although it is possible to do some of them self, adding some possibilities 
> from pattern matching directly in DRILL
>  * may be usefull,
>  * would prevent (re)write them and check again and again,
>  * would allow a quicker and more effective handling of Drill.
> Some propositions :
>  * adding possibilities to regexp_replace (ignoreCase, 
> replaceAll(currently)/replaceOnlyFirst ...)
>  * regexp_matches (lighter and more consistent than using regexp_replace 
> trick)
>  * split_to_table
> {noformat}
> SELECT split_to_table('Drill,baby,drill',',') AS mywords, 1 AS x;
> +-+---+
> | mywords | x |
> +-+---+
> | Drill   | 1 |
> | baby| 1 |
> | drill   | 1 |
> +-+---+
> {noformat}
>  * split_to_array
> {noformat}
> SELECT split_to_array('Drill,baby,drill',',') AS mywords, 1 AS x;
> +---+---+
> | mywords   | x |
> +---+---+
> | ["Drill","baby","drill"]  | 1 |
> +---+---+
> {noformat}
>  * ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DRILL-6981) command line option to choose/force drill-override.conf

2019-01-18 Thread Paul Rogers (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746604#comment-16746604
 ] 

Paul Rogers commented on DRILL-6981:


Are you on Linux? If so, then symlinks should work to share files.

On the other hand if you really do want to just change the 
{{drill-override.conf}} file, then doing so should be easy:

1. Add a new flag to drill-config.sh.
 2. In drill-config.sh where we work out the drill-override.conf location, add 
logic for your new flag.

The good news is that all this is just in a single shell script, 
drill-config.sh. You can try it on your local machine. Once you get it to work 
the way you like, issue a PR with the change.

> command line option to choose/force drill-override.conf 
> 
>
> Key: DRILL-6981
> URL: https://issues.apache.org/jira/browse/DRILL-6981
> Project: Apache Drill
>  Issue Type: Wish
>Affects Versions: 1.15.0
>Reporter: benj
>Priority: Minor
>
> It will be nice to have a command line option from sqlline to specify which 
> file to use to override instead of the natural drill-overide.conf.
> Example :
>  
> {code:java}
> ./sqlline --conf=../conf/another-drill-overide.conf
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (DRILL-6944) UnsupportedOperationException thrown for view over MapR-DB binary table

2019-01-18 Thread Vitalii Diravka (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746556#comment-16746556
 ] 

Vitalii Diravka edited comment on DRILL-6944 at 1/18/19 6:28 PM:
-

Merged with commit id de863afcd17447c3f2bb91a7ddd9f1c273a633a4


was (Author: vitalii):
Merged with commit id 8ad29864098656b9fdb4c1df1fb6ca031f8b9e7d

> UnsupportedOperationException thrown for view over MapR-DB binary table
> ---
>
> Key: DRILL-6944
> URL: https://issues.apache.org/jira/browse/DRILL-6944
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Data Types, Storage - MapRDB
>Affects Versions: 1.15.0
>Reporter: Igor Guzenko
>Assignee: Igor Guzenko
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.16.0
>
>
> 1. Create MapR-DB binary table and put some data using HBase shell:
> {code:none}
> hbase shell
> create '/tmp/bintable','name','address'
> put '/tmp/bintable','100','name:first_name','john'
> put '/tmp/bintable','100','name:last_name','doe'
> put '/tmp/bintable','100','address:city','Newark'
> put '/tmp/bintable','100','address:state','nj'
> scan '/tmp/bintable'
> {code}
> 2. Drill config: ensure that dfs storage plugin has "connection": 
> "maprfs:///" and contains format: 
> {code:java}
> "maprdb": {
> "type": "maprdb",
> "allTextMode": true,
> "enablePushdown": false,
> "disableCountOptimization": true
> }
> {code}
> 3. Check that table can be selected from Drill : 
> {code:java}
> select * from dfs.`/tmp/bintable`;
> {code}
> 4. Create Drill view 
> {code:java}
> create view dfs.tmp.`testview` as select * from dfs.`/tmp/bintable`;
> {code}
> 5. Query the view results into exception:
> {code:java}
> 0: jdbc:drill:> select * from dfs.tmp.`testview`;
> Error: SYSTEM ERROR: UnsupportedOperationException: Unable to convert cast 
> expression CastExpression [input=`address`, type=minor_type: MAP
> mode: REQUIRED
> ] into string.
> Please, refer to logs for more information.
> [Error Id: 109acd00-7456-4a74-8a17-485f8999000f on node1.cluster.com:31010] 
> (state=,code=0)
> {code}
> *UPDATE*
> This issue may be reproduced also when avro files with map columns are 
> queried using Drill. Appropriate test was added to PR commit. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (DRILL-6969) Inconsistent results when reading MaprDB JSON tables using hive plugin when native reader is enabled

2019-01-18 Thread Vitalii Diravka (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746554#comment-16746554
 ] 

Vitalii Diravka edited comment on DRILL-6969 at 1/18/19 6:27 PM:
-

Merged with commit id 95d91f40c5991720b6f9d1cd2147edf58c8b136f


was (Author: vitalii):
Merged with commit id 9e907860a7112a3dd13125b84a4693b05f53a9eb

> Inconsistent results when reading MaprDB JSON tables using hive plugin when 
> native reader is enabled
> 
>
> Key: DRILL-6969
> URL: https://issues.apache.org/jira/browse/DRILL-6969
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Volodymyr Vysotskyi
>Assignee: Volodymyr Vysotskyi
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.16.0
>
>
> Steps to reproduce:
> 0. Set PST timezone.
> 1. Create the table in MaprDB shell:
> {code}
> create /tmp/testtimestamp
> insert /tmp/testtimestamp --value '{"_id":"1","datestring":"2018-01-01 
> 12:12:12.123","datetimestamp":{"$date":"2018-01-01T20:12:12.123Z"}}'
> insert /tmp/testtimestamp --value '{"_id":"2","datestring":"-12-31 
> 23:59:59.999","datetimestamp":{"$date":"1-01-01T07:59:59.999Z"}}'
> {code}
> 2. Create a hive table:
> {code:sql}
> create external table `testtimestamp` (`_id` string, datestring string, 
> datetimestamp timestamp)
> ROW FORMAT SERDE 'org.apache.hadoop.hive.maprdb.json.serde.MapRDBSerDe'
> STORED BY 'org.apache.hadoop.hive.maprdb.json.MapRDBJsonStorageHandler'
> TBLPROPERTIES ( 'maprdb.column.id'='_id', 
> 'maprdb.table.name'='/tmp/testtimestamp');
> {code}
> 3. Disable native reader and run the query on the table from Drill using hive 
> plugin:
> {code:sql}
> alter session set 
> store.hive.maprdb_json.optimize_scan_with_native_reader=false;
> select * from hive.testtimestamp;
> {code}
> It returns:
> {noformat}
> +--+--+--+
> | _id  |datestring|  datetimestamp   |
> +--+--+--+
> | 1| 2018-01-01 12:12:12.123  | 2018-01-01 12:12:12.123  |
> | 2| -12-31 23:59:59.999  | -12-31 23:59:59.999  |
> +--+--+--+
> {noformat}
> 4. Enable native reader and run the query on the same table:
> {code:sql}
> alter session set 
> store.hive.maprdb_json.optimize_scan_with_native_reader=true;
> select * from hive.testtimestamp;
> {code}
> It returns:
> {noformat}
> +--+--+---+
> | _id  |datestring|   datetimestamp   |
> +--+--+---+
> | 1| 2018-01-01 12:12:12.123  | 2018-01-01 20:12:12.123   |
> | 2| -12-31 23:59:59.999  | 1-01-01 07:59:59.999  |
> +--+--+---+
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (DRILL-6971) Display query state in query result page

2019-01-18 Thread Vitalii Diravka (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746553#comment-16746553
 ] 

Vitalii Diravka edited comment on DRILL-6971 at 1/18/19 6:27 PM:
-

Merged with two commits:
4355e979e81ef7353b6e48b19283e0765e9a14bf
da7cb4e2fc67393f0ef26b0a03954ad139fdf7f9


was (Author: vitalii):
Merged with two commits:
19711c7b5f3179cb8826bed9f20ed38e7488f577
bf52c10c06b3ffdd65cdd278383b2261b67d743f

> Display query state in query result page
> 
>
> Key: DRILL-6971
> URL: https://issues.apache.org/jira/browse/DRILL-6971
> Project: Apache Drill
>  Issue Type: Improvement
>  Components: Web Server
>Affects Versions: 1.15.0
>Reporter: Sorabh Hamirwasia
>Assignee: Sorabh Hamirwasia
>Priority: Major
>  Labels: ready-to-commit, user-experience
> Fix For: 1.16.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Currently Query Result page doesn't show any state of the query. For 
> cancellation scenarios when there is no results fetched then it just shows No 
> Result Found and when partial results are returned then it will show the 
> returned data. Though user can look into the query state in profile page they 
> have to navigate away from result. It will be useful to know about the query 
> state with the result in same page.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DRILL-6967) TIMESTAMPDIFF returns incorrect value for SQL_TSI_QUARTER

2019-01-18 Thread Vitalii Diravka (JIRA)


 [ 
https://issues.apache.org/jira/browse/DRILL-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitalii Diravka updated DRILL-6967:
---
Labels: ready-to-commit  (was: )

> TIMESTAMPDIFF returns incorrect value for SQL_TSI_QUARTER
> -
>
> Key: DRILL-6967
> URL: https://issues.apache.org/jira/browse/DRILL-6967
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Functions - Drill
>Affects Versions: 1.15.0
>Reporter: Abhishek Ravi
>Assignee: Volodymyr Vysotskyi
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.16.0
>
>
> When checking the fix for DRILL-3610, I noticed that the value returned by 
> {{TIMESTAMPDIFF}} for {{SQL_TSI_QUARTER}} is incorrect.
> For example, consider the following queries on {{orders}} table with TPC-H 
> SF100 data
> Let's get a row from orders table
> {noformat}
> 0: jdbc:drill:drillbits=10.10.100.188> select * from orders limit 1;
> +-+++---+--+--+--+-++
> | o_orderkey  | o_custkey  | o_orderstatus  | o_totalprice  | o_orderdate  | 
> o_orderpriority  | o_clerk  | o_shippriority  | 
> o_comment  |
> +-+++---+--+--+--+-++
> | 456460071   | 9573185| O  | 234213.28 | 1998-03-09   | 
> 4-NOT SPECIFIED  | Clerk#65824  | 0   | r deposits. quickly 
> even ideas haggle flu  |
> +-+++---+--+--+--+-++
> {noformat}
> Now let's use {{TIMESTAMPADD}} to get the date 8 quarters / 2 years ago
> {noformat}
> 0: jdbc:drill:drillbits=10.10.100.188> select 
> cast(TIMESTAMPADD(SQL_TSI_QUARTER,-8,o_orderdate) as DATE) AS quarterdate 
> from orders where o_orderkey = 456460071;
> +--+
> | quarterdate  |
> +--+
> | 1996-03-09   |
> +--+
> {noformat}
> So far, so good.
> Now let's query the difference between the date in the row and the date 
> returned by TIMESTAMPADD (a date from 8 quarters ago)
> {noformat}
> 0: jdbc:drill:drillbits=10.10.100.188> select 
> TIMESTAMPDIFF(SQL_TSI_QUARTER,TO_DATE('1996-03-09','-MM-dd'),o_orderdate) 
> AS quarterdiff from orders where o_orderkey = 456460071;
> +--+
> | quarterdiff  |
> +--+
> | 6|
> +--+
> {noformat}
> *6 is incorrect!*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DRILL-6944) UnsupportedOperationException thrown for view over MapR-DB binary table

2019-01-18 Thread Vitalii Diravka (JIRA)


 [ 
https://issues.apache.org/jira/browse/DRILL-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitalii Diravka updated DRILL-6944:
---
Labels: ready-to-commit  (was: )

> UnsupportedOperationException thrown for view over MapR-DB binary table
> ---
>
> Key: DRILL-6944
> URL: https://issues.apache.org/jira/browse/DRILL-6944
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Data Types, Storage - MapRDB
>Affects Versions: 1.15.0
>Reporter: Igor Guzenko
>Assignee: Igor Guzenko
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.16.0
>
>
> 1. Create MapR-DB binary table and put some data using HBase shell:
> {code:none}
> hbase shell
> create '/tmp/bintable','name','address'
> put '/tmp/bintable','100','name:first_name','john'
> put '/tmp/bintable','100','name:last_name','doe'
> put '/tmp/bintable','100','address:city','Newark'
> put '/tmp/bintable','100','address:state','nj'
> scan '/tmp/bintable'
> {code}
> 2. Drill config: ensure that dfs storage plugin has "connection": 
> "maprfs:///" and contains format: 
> {code:java}
> "maprdb": {
> "type": "maprdb",
> "allTextMode": true,
> "enablePushdown": false,
> "disableCountOptimization": true
> }
> {code}
> 3. Check that table can be selected from Drill : 
> {code:java}
> select * from dfs.`/tmp/bintable`;
> {code}
> 4. Create Drill view 
> {code:java}
> create view dfs.tmp.`testview` as select * from dfs.`/tmp/bintable`;
> {code}
> 5. Query the view results into exception:
> {code:java}
> 0: jdbc:drill:> select * from dfs.tmp.`testview`;
> Error: SYSTEM ERROR: UnsupportedOperationException: Unable to convert cast 
> expression CastExpression [input=`address`, type=minor_type: MAP
> mode: REQUIRED
> ] into string.
> Please, refer to logs for more information.
> [Error Id: 109acd00-7456-4a74-8a17-485f8999000f on node1.cluster.com:31010] 
> (state=,code=0)
> {code}
> *UPDATE*
> This issue may be reproduced also when avro files with map columns are 
> queried using Drill. Appropriate test was added to PR commit. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DRILL-6964) Implement CREATE / DROP TABLE SCHEMA commands

2019-01-18 Thread Arina Ielchiieva (JIRA)


 [ 
https://issues.apache.org/jira/browse/DRILL-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arina Ielchiieva updated DRILL-6964:

Reviewer: Volodymyr Vysotskyi

> Implement CREATE / DROP TABLE SCHEMA commands
> -
>
> Key: DRILL-6964
> URL: https://issues.apache.org/jira/browse/DRILL-6964
> Project: Apache Drill
>  Issue Type: Sub-task
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
>Priority: Major
> Fix For: 1.16.0
>
>
> Design doc - 
> https://docs.google.com/document/d/1mp4egSbNs8jFYRbPVbm_l0Y5GjH3HnoqCmOpMTR_g4w/edit



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DRILL-6962) Function coalesce returns an Error when none of the columns in coalesce exist in a parquet file

2019-01-18 Thread benj (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746340#comment-16746340
 ] 

benj commented on DRILL-6962:
-

Exact, the correct syntax (that works) is :

 
{code:java}
SELECT COALESCE(CAST(NULL AS int), CAST(NULL AS int)) ex;
|  ex   |
+---+
| null  |{code}
 

In reality, and in a strange way, only one of the NULL passed in the COALESCE 
have to be CAST so
{code:java}
SELECT COALESCE(NULL, CAST(NULL AS int)); OK
SELECT COALESCE(CAST(NULL AS int), NULL); OK
{code}
I missed the point of the type cast because I was confused by the error message 
that maybe should have been "+Illegal use of 'NULL'+" like in

 
{code:java}
SELECT NULL;
Error: VALIDATION ERROR: From line 1, column 8 to line 1, column 11: Illegal 
use of 'NULL'
{code}
And in a last point for general knowledge :
 * Why the version of COALESCE with non typed NULL works
 * Why if the COALESCE version with only one defined type works, the next 
version doesn't work

{code:java}
SELECT CAST(COALESCE(NULL, NULL) AS int);
Error: VALIDATION ERROR: From line 1, column 13 to line 1, column 32: ELSE 
clause or at least one THEN clause must be non-NULL
{code}
 

 

> Function coalesce returns an Error when none of the columns in coalesce exist 
> in a parquet file
> ---
>
> Key: DRILL-6962
> URL: https://issues.apache.org/jira/browse/DRILL-6962
> Project: Apache Drill
>  Issue Type: Improvement
>Affects Versions: 1.13.0
>Reporter: Bohdan Kazydub
>Assignee: Bohdan Kazydub
>Priority: Major
> Fix For: 1.16.0
>
>
> As Drill is schema-free, COALESCE function is expected to return a result and 
> not error out even if none of the columns being referred to exists in files 
> being queried.
> Here is an example for 2 columns, `unk_col` and `unk_col2`, which do not 
> exist in the parquet files
> {code:java}
> select coalesce(unk_col, unk_col2) from dfs.`/tmp/parquetfiles`;
> java.lang.IndexOutOfBoundsException: index (0) must be less than size (0)
> at 
> org.apache.drill.shaded.guava.com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:1196)
> Fragment 1:0
> [Error Id: 7b9193fb-289b-4fbf-a52a-2b93b01f0cd0 on dkvm2c:31010] 
> (state=,code=0)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DRILL-6962) Function coalesce returns an Error when none of the columns in coalesce exist in a parquet file

2019-01-18 Thread Bohdan Kazydub (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746246#comment-16746246
 ] 

Bohdan Kazydub commented on DRILL-6962:
---

[~benj641] thank you for correcting error message. Regarding your second query 
with {{NULL}} literals - this is an expected behavior. The aim of the 
improvement is to allow using columns not present in queried files in 
{{coalesce}} function because some files may contain the mentioned columns and 
some may not.

> Function coalesce returns an Error when none of the columns in coalesce exist 
> in a parquet file
> ---
>
> Key: DRILL-6962
> URL: https://issues.apache.org/jira/browse/DRILL-6962
> Project: Apache Drill
>  Issue Type: Improvement
>Affects Versions: 1.13.0
>Reporter: Bohdan Kazydub
>Assignee: Bohdan Kazydub
>Priority: Major
> Fix For: 1.16.0
>
>
> As Drill is schema-free, COALESCE function is expected to return a result and 
> not error out even if none of the columns being referred to exists in files 
> being queried.
> Here is an example for 2 columns, `unk_col` and `unk_col2`, which do not 
> exist in the parquet files
> {code:java}
> select coalesce(unk_col, unk_col2) from dfs.`/tmp/parquetfiles`;
> java.lang.IndexOutOfBoundsException: index (0) must be less than size (0)
> at 
> org.apache.drill.shaded.guava.com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:1196)
> Fragment 1:0
> [Error Id: 7b9193fb-289b-4fbf-a52a-2b93b01f0cd0 on dkvm2c:31010] 
> (state=,code=0)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DRILL-6962) Function coalesce returns an Error when none of the columns in coalesce exist in a parquet file

2019-01-18 Thread Arina Ielchiieva (JIRA)


 [ 
https://issues.apache.org/jira/browse/DRILL-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arina Ielchiieva updated DRILL-6962:

Fix Version/s: 1.16.0

> Function coalesce returns an Error when none of the columns in coalesce exist 
> in a parquet file
> ---
>
> Key: DRILL-6962
> URL: https://issues.apache.org/jira/browse/DRILL-6962
> Project: Apache Drill
>  Issue Type: Improvement
>Affects Versions: 1.13.0
>Reporter: Bohdan Kazydub
>Assignee: Bohdan Kazydub
>Priority: Major
> Fix For: 1.16.0
>
>
> As Drill is schema-free, COALESCE function is expected to return a result and 
> not error out even if none of the columns being referred to exists in files 
> being queried.
> Here is an example for 2 columns, `unk_col` and `unk_col2`, which do not 
> exist in the parquet files
> {code:java}
> select coalesce(unk_col, unk_col2) from dfs.`/tmp/parquetfiles`;
> java.lang.IndexOutOfBoundsException: index (0) must be less than size (0)
> at 
> org.apache.drill.shaded.guava.com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:1196)
> Fragment 1:0
> [Error Id: 7b9193fb-289b-4fbf-a52a-2b93b01f0cd0 on dkvm2c:31010] 
> (state=,code=0)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DRILL-6783) CAST string literal as INTERVAL MONTH/YEAR works inconsistently when selecting from a table with multiple rows

2019-01-18 Thread Denys Ordynskiy (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746137#comment-16746137
 ] 

Denys Ordynskiy commented on DRILL-6783:


Tested with Drill version 1.16.0-SNAPSHOT  (commit 
172dc7cb4c3323e9650db2bf7fe1eab76c2fbbe1).
Cases verified:
- casting string month interval literal as "interval month";
- casting string month interval literal as "interval year";
- casting string month interval literal as "interval day";
- casting string day interval literal as "interval month";
- casting string day interval literal as "interval day".

> CAST string literal as INTERVAL MONTH/YEAR works inconsistently when 
> selecting from a table with multiple rows
> --
>
> Key: DRILL-6783
> URL: https://issues.apache.org/jira/browse/DRILL-6783
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Bohdan Kazydub
>Assignee: Bohdan Kazydub
>Priority: Critical
>  Labels: ready-to-commit
> Fix For: 1.15.0
>
>
> Casting string literal as INTERVAL MONTH or INTERVAL YEAR produces different 
> values for each row (actually, with period of 4) when selecting data from 
> table with more than one row.
> For example:
> {code}
> 0: jdbc:drill:zk=local> select cast('P314M' as interval month) from 
> cp.`employee.json` limit 10;
> +--+
> |  EXPR$0  |
> +--+
> | 26 years 2 months    |
> | 81089877 years 5 months  |
> | 1714858 years 8 months   |
> | 6698 years 8 months  |
> | 26 years 2 months    |
> | 81089877 years 5 months  |
> | 1714858 years 8 months   |
> | 6698 years 8 months  |
> | 26 years 2 months    |
> | 81089877 years 5 months  |
> +--+
> 10 rows selected (0.186 seconds)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DRILL-6976) SchemaChangeException happens when using split function in subquery if it returns empty result.

2019-01-18 Thread Bohdan Kazydub (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746132#comment-16746132
 ] 

Bohdan Kazydub commented on DRILL-6976:
---

The issue is fixed by DRILL-6962

> SchemaChangeException happens when using split function in subquery if it 
> returns empty result.
> ---
>
> Key: DRILL-6976
> URL: https://issues.apache.org/jira/browse/DRILL-6976
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Anton Gozhiy
>Assignee: Bohdan Kazydub
>Priority: Major
> Fix For: 1.16.0
>
>
> *Query:*
> {code:sql}
> select substr(col, 2, 3) 
> from (select split(n_comment, ' ') [3] col 
>   from cp.`tpch/nation.parquet` 
>   where n_nationkey = -1 
>   group by n_comment 
>   order by n_comment 
>   limit 5);
> {code}
> *Expected result:*
> {noformat}
> +-+
> | EXPR$0  |
> +-+
> +-+
> {noformat}
> *Actual result:*
> {noformat}
> Error: SYSTEM ERROR: SchemaChangeException: Failure while trying to 
> materialize incoming schema.  Errors:
>  
> Error in expression at index -1.  Error: Missing function implementation: 
> [castVARCHAR(NULL-OPTIONAL, BIGINT-REQUIRED)].  Full expression: --UNKNOWN 
> EXPRESSION--..
> Fragment 0:0
> Please, refer to logs for more information.
> [Error Id: 86515d74-7b9c-4949-8ece-c9c17e00afc3 on userf87d-pc:31010]
>   (org.apache.drill.exec.exception.SchemaChangeException) Failure while 
> trying to materialize incoming schema.  Errors:
>  
> Error in expression at index -1.  Error: Missing function implementation: 
> [castVARCHAR(NULL-OPTIONAL, BIGINT-REQUIRED)].  Full expression: --UNKNOWN 
> EXPRESSION--..
> 
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.setupNewSchemaFromInput():498
> 
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.setupNewSchema():583
> org.apache.drill.exec.record.AbstractUnaryRecordBatch.innerNext():101
> 
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext():143
> org.apache.drill.exec.record.AbstractRecordBatch.next():186
> org.apache.drill.exec.physical.impl.BaseRootExec.next():104
> 
> org.apache.drill.exec.physical.impl.ScreenCreator$ScreenRoot.innerNext():83
> org.apache.drill.exec.physical.impl.BaseRootExec.next():94
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run():297
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run():284
> java.security.AccessController.doPrivileged():-2
> javax.security.auth.Subject.doAs():422
> org.apache.hadoop.security.UserGroupInformation.doAs():1746
> org.apache.drill.exec.work.fragment.FragmentExecutor.run():284
> org.apache.drill.common.SelfCleaningRunnable.run():38
> java.util.concurrent.ThreadPoolExecutor.runWorker():1149
> java.util.concurrent.ThreadPoolExecutor$Worker.run():624
> java.lang.Thread.run():748 (state=,code=0)
> {noformat}
> *Note:* Filter "where n_nationkey = -1" doesn't return any rows. In case of " 
> = 1", for example, the query will return result without error.
> *Workaround:* Use cast on the split function, like
> {code:sql}
> cast(split(n_comment, ' ') [3] as varchar)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (DRILL-6642) Update protocol-buffers version

2019-01-18 Thread Anton Gozhiy (JIRA)


 [ 
https://issues.apache.org/jira/browse/DRILL-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anton Gozhiy reassigned DRILL-6642:
---

Assignee: Anton Gozhiy  (was: Anton Gozhiy)

> Update protocol-buffers version
> ---
>
> Key: DRILL-6642
> URL: https://issues.apache.org/jira/browse/DRILL-6642
> Project: Apache Drill
>  Issue Type: Task
>  Components: Tools, Build  Test
>Affects Versions: 1.14.0
>Reporter: Vitalii Diravka
>Assignee: Anton Gozhiy
>Priority: Major
> Fix For: 1.16.0
>
>
> Currently Drill uses 2.5.0 {{protocol-buffers}} version.
>  The last version is 3.6.0 in maven repo: 
> [https://mvnrepository.com/artifact/com.google.protobuf/protobuf-java]
> The new version has a lot of useful enhancements, which can be used in Drill.
>  One of them is using {{UNRECOGNIZED Enum NullValue}}, which can help to 
> handle them in place of null values for {{ProtocolMessageEnum}} - DRILL-6639. 
>  Looks like the NullValue can be used instead of null returned from 
> {{valueOf()}} (_or {{forNumber()}}, since {{valueOf()}} is deprecated in the 
> newer protobuf version_):
>  
> [https://developers.google.com/protocol-buffers/docs/reference/java/com/google/protobuf/NullValue]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (DRILL-6962) Function coalesce returns an Error when none of the columns in coalesce exist in a parquet file

2019-01-18 Thread Bohdan Kazydub (JIRA)


 [ 
https://issues.apache.org/jira/browse/DRILL-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bohdan Kazydub updated DRILL-6962:
--
Description: 
As Drill is schema-free, COALESCE function is expected to return a result and 
not error out even if none of the columns being referred to exists in files 
being queried.

Here is an example for 2 columns, `unk_col` and `unk_col2`, which do not exist 
in the parquet files
{code:java}
select coalesce(unk_col, unk_col2) from dfs.`/tmp/parquetfiles`;
java.lang.IndexOutOfBoundsException: index (0) must be less than size (0)
at 
org.apache.drill.shaded.guava.com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:1196)

Fragment 1:0

[Error Id: 7b9193fb-289b-4fbf-a52a-2b93b01f0cd0 on dkvm2c:31010] (state=,code=0)
{code}

  was:
As Drill is schema-free, COALESCE function is expected to return a result and 
not error out even if none of the columns being referred to exists in files 
being queried.

Here is an example for 2 columns, `unk_col` and `unk_col2`, which do not exist 
in the parquet files
{code:java}
select coalesce(unk_col, unk_col2) from dfs.`/tmp/parquetfiles`;
Error: SYSTEM ERROR: CompileException: Line 56, Column 27: Assignment 
conversion not possible from type 
“org.apache.drill.exec.expr.holders.NullableIntHolder” to type 
“org.apache.drill.exec.vector.UntypedNullHolder”

Fragment 1:0

[Error Id: 7b9193fb-289b-4fbf-a52a-2b93b01f0cd0 on dkvm2c:31010] (state=,code=0)
{code}


> Function coalesce returns an Error when none of the columns in coalesce exist 
> in a parquet file
> ---
>
> Key: DRILL-6962
> URL: https://issues.apache.org/jira/browse/DRILL-6962
> Project: Apache Drill
>  Issue Type: Improvement
>Affects Versions: 1.13.0
>Reporter: Bohdan Kazydub
>Assignee: Bohdan Kazydub
>Priority: Major
>
> As Drill is schema-free, COALESCE function is expected to return a result and 
> not error out even if none of the columns being referred to exists in files 
> being queried.
> Here is an example for 2 columns, `unk_col` and `unk_col2`, which do not 
> exist in the parquet files
> {code:java}
> select coalesce(unk_col, unk_col2) from dfs.`/tmp/parquetfiles`;
> java.lang.IndexOutOfBoundsException: index (0) must be less than size (0)
> at 
> org.apache.drill.shaded.guava.com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:1196)
> Fragment 1:0
> [Error Id: 7b9193fb-289b-4fbf-a52a-2b93b01f0cd0 on dkvm2c:31010] 
> (state=,code=0)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DRILL-6981) command line option to choose/force drill-override.conf

2019-01-18 Thread benj (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-6981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745906#comment-16745906
 ] 

benj commented on DRILL-6981:
-

I agree with that.

But with several instance with common/identical files on these directories, 
it's annoying to update the files of each directory. So currently I work with 
script that replace the particulars file before launching (only 
drill-override.sh in my case), but I had imagined having a (complementary) 
finest option could be useful (or maybe a meta-conf file that could precise the 
location of each item).

But maybe it's too special (or too bad practice) if nobody has the same 
use/need.

> command line option to choose/force drill-override.conf 
> 
>
> Key: DRILL-6981
> URL: https://issues.apache.org/jira/browse/DRILL-6981
> Project: Apache Drill
>  Issue Type: Wish
>Affects Versions: 1.15.0
>Reporter: benj
>Priority: Minor
>
> It will be nice to have a command line option from sqlline to specify which 
> file to use to override instead of the natural drill-overide.conf.
> Example :
>  
> {code:java}
> ./sqlline --conf=../conf/another-drill-overide.conf
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)