[jira] [Resolved] (DRILL-4394) Can’t build the custom functions for Apache Drill 1.5.0

[Jason Altekruse (JIRA)]

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

Jason Altekruse resolved DRILL-4394.

Resolution: Fixed
  Assignee: Jason Altekruse

> Can’t build the custom functions for Apache Drill 1.5.0
> ---
>
> Key: DRILL-4394
> URL: https://issues.apache.org/jira/browse/DRILL-4394
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.5.0
>Reporter: Kumiko Yada
>Assignee: Jason Altekruse
>Priority: Critical
>
> I tried to build the custom functions for Drill 1.5.0, but I got the below 
> error:
> Failure to find org.apache.drill.exec:drill-java-exec:jar:1.5.0 in 
> http://repo.maven.apache.org/maven2 was cached in the local repository.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DRILL-4435) Add YARN jar required for running Drill on cluster with Kerberos

[Jason Altekruse (JIRA)]

Jason Altekruse created DRILL-4435:
--

 Summary: Add YARN jar required for running Drill on cluster with 
Kerberos
 Key: DRILL-4435
 URL: https://issues.apache.org/jira/browse/DRILL-4435
 Project: Apache Drill
  Issue Type: Improvement
Reporter: Jason Altekruse
Assignee: Jason Altekruse


As described here, Drill currently requires adding a YARN jar to the classpath 
to run on Kerberos. If it doesn't conflict with any jars currently included 
with Drill we should just include this in the distribution to make this work 
out of the box.

http://www.dremio.com/blog/securing-sql-on-hadoop-part-2-installing-and-configuring-drill/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DRILL-3229) Create a new EmbeddedVector

[Jason Altekruse (JIRA)]

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

Jason Altekruse resolved DRILL-3229.

   Resolution: Fixed
Fix Version/s: (was: Future)
   1.4.0

> Create a new EmbeddedVector
> ---
>
> Key: DRILL-3229
> URL: https://issues.apache.org/jira/browse/DRILL-3229
> Project: Apache Drill
>  Issue Type: Sub-task
>  Components: Execution - Codegen, Execution - Data Types, Execution - 
> Relational Operators, Functions - Drill
>Reporter: Jacques Nadeau
>Assignee: Steven Phillips
> Fix For: 1.4.0
>
>
> Embedded Vector will leverage a binary encoding for holding information about 
> type for each individual field.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DRILL-284) Publish artifacts to maven for Drill

[Jason Altekruse (JIRA)]

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

Jason Altekruse resolved DRILL-284.
---
   Resolution: Fixed
Fix Version/s: (was: Future)
   1.1.0

> Publish artifacts to maven for Drill
> 
>
> Key: DRILL-284
> URL: https://issues.apache.org/jira/browse/DRILL-284
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Timothy Chen
> Fix For: 1.1.0
>
>
> We need to publish our artifacts and version to maven so other dependencies 
> (Whirr, or other ones that wants maven include) can use.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] drill pull request: DRILL-4434: Deprecate GroupScan.enforceWidth A...

[sudheeshkatkam]

Github user sudheeshkatkam commented on the pull request:

https://github.com/apache/drill/pull/390#issuecomment-188532721
  
Sounds good.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill pull request: DRILL-4434: Deprecate GroupScan.enforceWidth A...

[vkorukanti]

Github user vkorukanti commented on the pull request:

https://github.com/apache/drill/pull/390#issuecomment-188531968
  
Not sure of the policy around changing public APIs, but I think it is 
better to keep the method around to avoid breaking existing storage plugins 
until next major version release (2.x)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Cassandra

[Naveed Ahmad]

Hello All,

I would like to configure Apache Drill with Cassandra. I have read a few blogs 
inline however their solutions dont work with the latest Cassandra/Drill 
releases. Do you guys know how I can achieve this?

Many thanks for your help upfront.

Kind Regards

Naveed
 

---
Naveed Ahmad
Mob# +44 (0) 77 99 075 036

[GitHub] drill pull request: DRILL-4434: Deprecate GroupScan.enforceWidth A...

[vkorukanti]

GitHub user vkorukanti opened a pull request:

https://github.com/apache/drill/pull/390

DRILL-4434: Deprecate GroupScan.enforceWidth API



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vkorukanti/drill DRILL-4434

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/drill/pull/390.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #390


commit 3e55fe1db23e51e39043e3f366b6d1c6bfb73a9c
Author: vkorukanti 
Date:   2016-02-24T22:13:21Z

DRILL-4434: Deprecate GroupScan.enforceWidth API




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill pull request: DRILL-4411: hash join should limit batch based...

[jaltekruse]

Github user jaltekruse commented on a diff in the pull request:

https://github.com/apache/drill/pull/381#discussion_r54018324
  
--- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/join/HashJoinProbeTemplate.java
 ---
@@ -98,7 +102,9 @@ public void setupHashJoinProbe(FragmentContext context, 
VectorContainer buildBat
   }
 
   public void executeProjectRightPhase() {
-while (outputRecords < TARGET_RECORDS_PER_BATCH && recordsProcessed < 
recordsToProcess) {
+while (outputRecords < targetRecordsPerBatch
+&& recordsProcessed < recordsToProcess
+&& (!adjustTargetRecordsPerBatch || 
outgoingJoinBatch.getMemoryUsed() < TARGET_BATCH_SIZE_IN_BYTES)) {
--- End diff --

It seems like the thing we are testing for here isn't actually directly 
related to the condition we are trying to avoid. The overall memory consumed 
when outputting records will be a function of both size of values as well as 
number of columns. I think this is a reasonable approach for now but we should 
open a follow-up JIRA to look at where things will break as we encounter cases 
where there are many wide columns in a dataset.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill pull request: DRILL-4411: hash join should limit batch based...

[jaltekruse]

Github user jaltekruse commented on a diff in the pull request:

https://github.com/apache/drill/pull/381#discussion_r54017535
  
--- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/join/HashJoinProbeTemplate.java
 ---
@@ -47,7 +47,11 @@
 
   private HashJoinBatch outgoingJoinBatch = null;
 
-  private static final int TARGET_RECORDS_PER_BATCH = 4000;
+  private int targetRecordsPerBatch = 4000;
+
+  private boolean adjustTargetRecordsPerBatch = true;
--- End diff --

It looks like this flag is designed to allow the adjustment to only happen 
once, is that actually what we want? If the row size is growing it would seem 
like a good idea to allow for several batch size adjustments. It also removes 
another boolean state to manage.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill pull request: DRILL-4411: hash join should limit batch based...

[jaltekruse]

Github user jaltekruse commented on a diff in the pull request:

https://github.com/apache/drill/pull/381#discussion_r54017219
  
--- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/join/HashJoinProbeTemplate.java
 ---
@@ -47,7 +47,11 @@
 
   private HashJoinBatch outgoingJoinBatch = null;
 
-  private static final int TARGET_RECORDS_PER_BATCH = 4000;
+  private int targetRecordsPerBatch = 4000;
--- End diff --

I would add a comment here about when this value will be mutated as we are 
moving it away from immutability, and most of the other operators currently 
have this as an immutable value.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: hive translate function is not working from Drill

[Jinfeng Ni]

Checked standard SQL reference,  ISO/IEC 9075-2:2011(E), section 6.30

 ::=
  TRANSLATE  
USING  

Looks like Calcite follows the standard SQL reference.


On Wed, Feb 24, 2016 at 1:46 PM, Jinfeng Ni  wrote:
> Looks like Calcite, the SQL parser that Drill uses, treats translate
> as a build-in function : translate( expression USING identifier).
> That's why you saw the Parser error.
>
>
> [1] 
> https://github.com/apache/calcite/blob/master/core/src/main/codegen/templates/Parser.jj#L3987-L4005
>
> On Wed, Feb 24, 2016 at 1:23 PM, Arina Yelchiyeva
>  wrote:
>> Hi all!
>>
>> Does all Hive functions work in Drill?
>>
>> I have faced the issue with translate function.
>> In Hive "select translate(name, 'A', 'B') from users" works fine.
>> But in Drill "select translate(name, 'A', 'B') from hive.`users`" return
>> the following error:
>>
>> org.apache.drill.common.exceptions.UserRemoteException: PARSE ERROR:
>> Encountered "," at line 1, column 22. Was expecting one of: "USING" ...
>> "NOT" ... "IN" ... "BETWEEN" ... "LIKE" ... "SIMILAR" ... "=" ... ">" ...
>> "<" ... "<=" ... ">=" ... "<>" ... "+" ... "-" ... "*" ... "/" ... "||" ...
>> "AND" ... "OR" ... "IS" ... "MEMBER" ... "SUBMULTISET" ... "MULTISET" ...
>> "[" ... "." ... "(" ... while parsing SQL query: select translate(name,
>> 'A', 'B') from hive.users ^ [Error Id: ba21956b-3285-4544-b3b2-fab68b95be1f
>> on localhost:31010]
>>
>> Am I missing something? Or I should create jira to fix for bug fix?
>>
>> Kind regards
>> Arina

Hangout notes from the last few meetings

[Jason Altekruse]

Hey guys,

Sorry I haven't been sending these out, I keep meaning to go back to them
and clean them up before sending them out and I don't get around to it. I
will just post the raw notes after the meeting going forward and provide
clarification on the thread if anyone has questions.


Drill Hangout - 2/9/2016

- Attendees: Yulia, Sean, Vicky, Sudheesh, Neeraja, Karol Potocki, Arina,
Aman, Hakim, Jinfeng

- New community members, Welcome!

- Arina

- working with MapR team

- Karol

- tiny contribution to allow spacial queries in Drill

- interested in sparking interest in geo locations

- PR outstanding for shapefile format

- Neeraja - would be nice for simple doc for users to start

- examples in PR and Karol's github repo

- he could write a blog post for the apache repo

- Discussion topics

- Sudheesh

- 4281 - client impersonation

- post a design doc soon

- some drill deployments

- tableau desktop is presentation layer on top of Drill

- users only use tableau desktop, talking through tableau server

- want to pass user from tableau desktop through the tableau
server

  so that impersonation works correctly

- requires a change in Tableau as well, working with the team
there

- Yulia

- 4132 - simple queries in parallel

- design doc on JIRA

- 2 goals

- separate planning from execution

- separate fragment plans so that they can be run independently

- those available please review design doc and PR

- 1.5.0

- new vote out soon

- Jinfeng

- 2517 - directory pruning in calcite logical

- vicky seems to have found a bug

- follow up work

- need to separate the rules and run them individually to

  improve planning performance

- Drill user survey

- other projects list who is using them

- just a google survey

- simple questions, I assume all will be considered optional

- current drill version in use

- cluster size

- datasources used

- clients: sqlline, REST, Applications, JDBC, ODBC, BI Tools

- what is your use case?

- why Drill?

- data formats, data types

- are you using any of the security features of Drill to
restrict access of some data to users?

- view chaining, impersonation, Web UI security

- SQL features you would like to see as enhancements soon?

- how many users are querying your Drill cluster

- have you written a storage plugin, UDF or format plugin?

- issues with the build

- jdbc-all jar size enforcement

- jacques made changes to remove proguard and generally fix up
jdbc-all JAR

- 1.4.0 has a large JDBC-all jar that wasn't excluding what it was
supposed to

- Aman

- Dechang - perf regressions on rc2 metadata cache


Drill Hangout - 2/16/2016

- Attendees: Parth, Andries, Arina, Jason, Vitalii

- Topics for discussion

- Release

- issues with publishing the web site

- annoucnement should be up shortly

- Jacques had mentioned Metadata caching

- follow up if he wants to post thoughts

- Discussion was short today


Drill Hangout - 2/23/2016

- Attendees: Jason, Minji, Laurent, Arina, Parth, Sudheesh, Zelaine


arina -- modify calcite, timestamp related function --> contact calcite
folks/julien


improve c++ client, better distribution of queries across cluster,
randomization routine not distributing uniformly.

session options not allowed since can't maintain sessions if uniformly
distributed

--> c++ client std c library rand() function not always good

--> different random number generator

--> new connnection in the pool, then need to keep track of all the
altersessions (temporary tables, new schema, etc.)

--> small number of clients, need foreman workload distributed more
(planning and so on)

--> ping jacques


impersonation--> client to impersonate other clients (Delegation?)

--> odbc/jdbc:  provide an api (c++/java) and how they will use it

--> waiting on comments


better testing for operator:  better tests for independent components

--> mock internal parts of systems

--> run operators in isolation (posting soon)

--> exchanges needs a bit more discussion (vector container) - separate way
to mock data coming in


juliens test changes to run tests on multiple drill bits (?)

--> This actually wasn't Julien's contribution as was in the meeting,
Sudheesh was actually referring to Andrew's PR here:
https://github.com/apache/drill/pull/135

Re: hive translate function is not working from Drill

[Jinfeng Ni]

Looks like Calcite, the SQL parser that Drill uses, treats translate
as a build-in function : translate( expression USING identifier).
That's why you saw the Parser error.


[1] 
https://github.com/apache/calcite/blob/master/core/src/main/codegen/templates/Parser.jj#L3987-L4005

On Wed, Feb 24, 2016 at 1:23 PM, Arina Yelchiyeva
 wrote:
> Hi all!
>
> Does all Hive functions work in Drill?
>
> I have faced the issue with translate function.
> In Hive "select translate(name, 'A', 'B') from users" works fine.
> But in Drill "select translate(name, 'A', 'B') from hive.`users`" return
> the following error:
>
> org.apache.drill.common.exceptions.UserRemoteException: PARSE ERROR:
> Encountered "," at line 1, column 22. Was expecting one of: "USING" ...
> "NOT" ... "IN" ... "BETWEEN" ... "LIKE" ... "SIMILAR" ... "=" ... ">" ...
> "<" ... "<=" ... ">=" ... "<>" ... "+" ... "-" ... "*" ... "/" ... "||" ...
> "AND" ... "OR" ... "IS" ... "MEMBER" ... "SUBMULTISET" ... "MULTISET" ...
> "[" ... "." ... "(" ... while parsing SQL query: select translate(name,
> 'A', 'B') from hive.users ^ [Error Id: ba21956b-3285-4544-b3b2-fab68b95be1f
> on localhost:31010]
>
> Am I missing something? Or I should create jira to fix for bug fix?
>
> Kind regards
> Arina

hive translate function is not working from Drill

[Arina Yelchiyeva]

Hi all!

Does all Hive functions work in Drill?

I have faced the issue with translate function.
In Hive "select translate(name, 'A', 'B') from users" works fine.
But in Drill "select translate(name, 'A', 'B') from hive.`users`" return
the following error:

org.apache.drill.common.exceptions.UserRemoteException: PARSE ERROR:
Encountered "," at line 1, column 22. Was expecting one of: "USING" ...
"NOT" ... "IN" ... "BETWEEN" ... "LIKE" ... "SIMILAR" ... "=" ... ">" ...
"<" ... "<=" ... ">=" ... "<>" ... "+" ... "-" ... "*" ... "/" ... "||" ...
"AND" ... "OR" ... "IS" ... "MEMBER" ... "SUBMULTISET" ... "MULTISET" ...
"[" ... "." ... "(" ... while parsing SQL query: select translate(name,
'A', 'B') from hive.users ^ [Error Id: ba21956b-3285-4544-b3b2-fab68b95be1f
on localhost:31010]

Am I missing something? Or I should create jira to fix for bug fix?

Kind regards
Arina

[jira] [Created] (DRILL-4434) Remove (or deprecate) GroupScan.enforceWidth and use GroupScan.getMinParallelization

[Venki Korukanti (JIRA)]

Venki Korukanti created DRILL-4434:
--

 Summary: Remove (or deprecate) GroupScan.enforceWidth and use 
GroupScan.getMinParallelization
 Key: DRILL-4434
 URL: https://issues.apache.org/jira/browse/DRILL-4434
 Project: Apache Drill
  Issue Type: Bug
Reporter: Venki Korukanti


It seems like enforceWidth is not necessary which is used only in 
ExcessibleExchangeRemover. Instead we should rely on 
GroupScan.getMinParallelization().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DRILL-4433) Unnecessary entries created in ZK when a jdbc application uses a wrong connection URL

[Rahul Challapalli (JIRA)]

Rahul Challapalli created DRILL-4433:


 Summary: Unnecessary entries created in ZK when a jdbc application 
uses a wrong connection URL 
 Key: DRILL-4433
 URL: https://issues.apache.org/jira/browse/DRILL-4433
 Project: Apache Drill
  Issue Type: Bug
  Components: Client - JDBC
Reporter: Rahul Challapalli


commit # : 6d5f4983003b8f5d351adcb0bc9881d2dc4c2d3f
commit date : Feb 22, 2016

In my JDBC application, I accidentally used an invalid connection string like 
below
{code}
jdbc:drill:zk=x.x.x.x:5181/zkroot-blah/cluster-name
{code}
While drill correctly reported an "No DrillbitEndpoint can be found error", I 
also observed that it created an entry in zookeeper by the name "zkroot-blah". 
There seems to be no reason for doing this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DRILL-4432) Update error message to include all unsupported functions when frame clause is used

[Khurram Faraaz (JIRA)]

Khurram Faraaz created DRILL-4432:
-

 Summary: Update error message to include all unsupported functions 
when frame clause is used
 Key: DRILL-4432
 URL: https://issues.apache.org/jira/browse/DRILL-4432
 Project: Apache Drill
  Issue Type: Bug
  Components: SQL Parser
Affects Versions: 1.6.0
Reporter: Khurram Faraaz
Priority: Minor


We need to update the error message to include LEAD, LAG, NTILE, and ranking 
functions, right now we only say ROW/RANGE is not allowed with RANK, DENSE_RANK 
or ROW_NUMBER functions, when frame clause is used in the window definition of 
any of these window functions.

Another typo that needs fix in error message, it is not ROW/RANGE, it should be 
ROWS/RANGE (rows not row)

An example of current error message that we see.
{noformat}
0: jdbc:drill:schema=dfs.tmp> select LEAD(columns[3]) OVER(PARTITION BY 
CAST(columns[0] as integer) ORDER BY cast(columns[0] as integer) ROWS UNBOUNDED 
PRECEDING) from dfs.tmp.`t_alltype.csv`;
Error: VALIDATION ERROR: From line 1, column 108 to line 1, column 111: 
ROW/RANGE not allowed with RANK, DENSE_RANK or ROW_NUMBER functions


[Error Id: 98565028-bfd8-4f57-acdb-5235195d3d6d on centos-01.qa.lab:31010] 
(state=,code=0)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DRILL-4431) NTILE function should NOT allow the use of frame clause in its window definition

[Khurram Faraaz (JIRA)]

Khurram Faraaz created DRILL-4431:
-

 Summary: NTILE function should NOT allow the use of frame clause 
in its window definition
 Key: DRILL-4431
 URL: https://issues.apache.org/jira/browse/DRILL-4431
 Project: Apache Drill
  Issue Type: Bug
  Components: Query Planning & Optimization
Affects Versions: 1.6.0
Reporter: Khurram Faraaz


NTILE function should not allow the use of frame clause in its window 
definition, the below query should return and error and say the operation is 
not supported.

Drill 1.6.0, commit ID: 6d5f4983

The SQL spec says NTILE should not allow use of frame clause.
{noformat}
>From the SQL SPEC on page 220
ISO/IEC 9075-2:2011(E)
6.10

7)



If , ,  or ROW_NUMBER 
is specified, then:

a)  If , , RANK or DENSE_RANK is 
specified, then the window

ordering clause WOC of WDX shall be present.

b)  The window framing clause of WDX shall not be present. 
{noformat}

{noformat}
0: jdbc:drill:schema=dfs.tmp> select NTILE(3) OVER(PARTITION BY CAST(columns[0] 
as integer) ORDER BY cast(columns[0] as integer) ROWS UNBOUNDED PRECEDING) from 
dfs.tmp.`t_alltype.csv`;
+-+
| EXPR$0  |
+-+
| 1   |
| 1   |
| 1   |
...
...
| 1  |
| 1  |
| 1  |
++
145 rows selected (0.322 seconds)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DRILL-4430) Unable to execute drill jdbc from jboss container

[abhishek agrawal (JIRA)]

abhishek agrawal created DRILL-4430:
---

 Summary: Unable to execute drill jdbc from jboss container
 Key: DRILL-4430
 URL: https://issues.apache.org/jira/browse/DRILL-4430
 Project: Apache Drill
  Issue Type: Bug
  Components: Client - JDBC
Affects Versions: 1.5.0
 Environment: Linux
Windows 7
Jboss 7.1
Reporter: abhishek agrawal


Unable to execute jdbc query from jboss application server. Its closing the 
connection with an error:
20:30:46,543 INFO  [org.apache.curator.framework.state.ConnectionStateManager] 
(http--0.0.0.0-8080-1-EventThread) State change: CONNECTED
20:30:47,609 ERROR [org.apache.drill.exec.rpc.RpcExceptionHandler] (Client-1) 
Exception in RPC communication.  Connection: /172.18.129.2:39687 <--> 
INBBRDSSVM265/172.18.129.2:31010 (user client).  Closing connection.
20:30:47,614 INFO  [org.apache.drill.exec.rpc.user.UserClient] (Client-1) 
Channel closed /172.18.129.2:39687 <--> INBBRDSSVM265/172.18.129.2:31010.
20:30:47,614 INFO  [org.apache.drill.exec.rpc.user.QueryResultHandler] 
(Client-1) User Error Occurred: 
org.apache.drill.common.exceptions.UserException: CONNECTION ERROR: Connection 
/172.18.129.2:39687 <--> INBBRDSSVM265/172.18.129.2:31010 (user client) closed 
unexpectedly.

Note: the same code with right dependency works fine with standalone java code.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DRILL-4429) Need a better error message when window frame exclusion is used in frame-clause

[Khurram Faraaz (JIRA)]

Khurram Faraaz created DRILL-4429:
-

 Summary: Need a better error message when window frame exclusion 
is used in frame-clause
 Key: DRILL-4429
 URL: https://issues.apache.org/jira/browse/DRILL-4429
 Project: Apache Drill
  Issue Type: Bug
  Components: SQL Parser
Affects Versions: 1.6.0
Reporter: Khurram Faraaz
Priority: Minor


We need to report a proper error message to user when window frame exclusion is 
used in the window frame-clause. Currently we do not support it and the current 
error message is not helpful.

Drill 1.6.0
commit ID: 6d5f4983

{noformat}
0: jdbc:drill:schema=dfs.tmp> select count(*) OVER(PARTITION BY CAST(columns[0] 
as integer) ORDER BY cast(columns[0] as integer) RANGE BETWEEN UNBOUNDED 
PRECEDING AND UNBOUNDED following EXCLUDE CURRENT ROW) from 
dfs.tmp.`t_alltype.csv`;
Error: PARSE ERROR: Encountered "EXCLUDE" at line 1, column 158.
Was expecting one of:
")" ...
"ALLOW" ...
"DISALLOW" ...


while parsing SQL query:
select count(*) OVER(PARTITION BY CAST(columns[0] as integer) ORDER BY 
cast(columns[0] as integer) RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED 
following EXCLUDE CURRENT ROW) from dfs.tmp.`t_alltype.csv`

 ^

[Error Id: ddfcd7fc-1a84-4e1f-8e51-34601e9155a6 on centos-04.qa.lab:31010] 
(state=,code=0)
{noformat}

>From the SQL specification, we need to add these.

{noformat}
 ::=
EXCLUDE CURRENT ROW
  | EXCLUDE GROUP
  | EXCLUDE TIES
  | EXCLUDE NO OTHERS
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DRILL-4428) Need a better error message when GROUPS keyword used in window frame-clause

[Khurram Faraaz (JIRA)]

Khurram Faraaz created DRILL-4428:
-

 Summary: Need a better error message when GROUPS keyword used in 
window frame-clause
 Key: DRILL-4428
 URL: https://issues.apache.org/jira/browse/DRILL-4428
 Project: Apache Drill
  Issue Type: Bug
  Components: SQL Parser
Affects Versions: 1.6.0
Reporter: Khurram Faraaz
Priority: Minor


We need to report a better message to user that we do not support (today) the 
use of GROUPS keyword as the window frame unit, in the window frame clause.

commit ID: 6d5f4983
Drill version : 1.6.0

{noformat}
0: jdbc:drill:schema=dfs.tmp> select count(*) OVER(PARTITION BY CAST(columns[0] 
as integer) GROUPS) from dfs.tmp.`t_alltype.csv`;
Error: PARSE ERROR: Encountered "GROUPS" at line 1, column 63.
Was expecting one of:
")" ...
"," ...
"ORDER" ...
"ROWS" ...
"RANGE" ...
"ALLOW" ...
"DISALLOW" ...
"NOT" ...
"IN" ...
"BETWEEN" ...
"LIKE" ...
"SIMILAR" ...
"=" ...
">" ...
"<" ...
"<=" ...
">=" ...
"<>" ...
"+" ...
"-" ...
"*" ...
"/" ...
"||" ...
"AND" ...
"OR" ...
"IS" ...
"MEMBER" ...
"SUBMULTISET" ...
"MULTISET" ...
"[" ...


while parsing SQL query:
select count(*) OVER(PARTITION BY CAST(columns[0] as integer) GROUPS) from 
dfs.tmp.`t_alltype.csv`
  ^

[Error Id: f08e924a-bde9-48c4-bc7b-cb32c96908f2 on centos-04.qa.lab:31010] 
(state=,code=0)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)