date:20150720


[ 
https://issues.apache.org/jira/browse/DRILL-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633898#comment-14633898
 ] 

Jason Altekruse commented on DRILL-3521:


Taking a closer look at my example, this switch is evaluated on an Enum, so 
this might be the correct behavior. I will keep the bug open as I know there 
are other such issues elsewhere. I will hopefully be updating this issue with 
some examples soon.

 [umbrella] Review switch statements throughout codebase to add default cases 
 where there are none
 -

 Key: DRILL-3521
 URL: https://issues.apache.org/jira/browse/DRILL-3521
 Project: Apache Drill
  Issue Type: Bug
  Components: Execution - Flow
Reporter: Jason Altekruse
Assignee: Jason Altekruse
 Fix For: 1.3.0


 There are a number of places in the code that are missing default branches on 
 case statements. One particular instance I noticed is in 
 OptionValue.createOption, which returns null if passed an unexpected type. 
 This and a few other places in the code could be made a little nicer to work 
 with if we just provided the standard behavior of throwing an exception (or a 
 documented default value that will make sense in a few contexts).
 One additional note, in a number of places where we do have defaults, but the 
 exception thrown is an UnsupportedOperationException with no message. 
 DRILL-2680 discusses this problem, so this might be handled over there, but 
 as we fill in the switch defaults we should try to avoid introducing the new 
 problem of exceptions lacking descriptions.



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

[jira] [Updated] (DRILL-3521) [umbrella] Review switch statements throughout codebase to add default cases where there are none


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

Jason Altekruse updated DRILL-3521:
---
Description: 
There are a number of places in the code that are missing default branches on 
case statements. -One particular instance I noticed is in 
OptionValue.createOption, which returns null if passed an unexpected type.- 
This and a few other places in the code could be made a little nicer to work 
with if we just provided the standard behavior of throwing an exception (or a 
documented default value that will make sense in a few contexts).

One additional note, in a number of places where we do have defaults, but the 
exception thrown is an UnsupportedOperationException with no message. 
DRILL-2680 discusses this problem, so this might be handled over there, but as 
we fill in the switch defaults we should try to avoid introducing the new 
problem of exceptions lacking descriptions.

  was:
There are a number of places in the code that are missing default branches on 
case statements. One particular instance I noticed is in 
OptionValue.createOption, which returns null if passed an unexpected type. This 
and a few other places in the code could be made a little nicer to work with if 
we just provided the standard behavior of throwing an exception (or a 
documented default value that will make sense in a few contexts).

One additional note, in a number of places where we do have defaults, but the 
exception thrown is an UnsupportedOperationException with no message. 
DRILL-2680 discusses this problem, so this might be handled over there, but as 
we fill in the switch defaults we should try to avoid introducing the new 
problem of exceptions lacking descriptions.


 [umbrella] Review switch statements throughout codebase to add default cases 
 where there are none
 -

 Key: DRILL-3521
 URL: https://issues.apache.org/jira/browse/DRILL-3521
 Project: Apache Drill
  Issue Type: Bug
  Components: Execution - Flow
Reporter: Jason Altekruse
Assignee: Jason Altekruse
 Fix For: 1.3.0


 There are a number of places in the code that are missing default branches on 
 case statements. -One particular instance I noticed is in 
 OptionValue.createOption, which returns null if passed an unexpected type.- 
 This and a few other places in the code could be made a little nicer to work 
 with if we just provided the standard behavior of throwing an exception (or a 
 documented default value that will make sense in a few contexts).
 One additional note, in a number of places where we do have defaults, but the 
 exception thrown is an UnsupportedOperationException with no message. 
 DRILL-2680 discusses this problem, so this might be handled over there, but 
 as we fill in the switch defaults we should try to avoid introducing the new 
 problem of exceptions lacking descriptions.



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

[jira] [Commented] (DRILL-3122) Changing a session option to default value results in status as changed


[ 
https://issues.apache.org/jira/browse/DRILL-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633906#comment-14633906
 ] 

ASF GitHub Bot commented on DRILL-3122:
---

Github user jaltekruse commented on the pull request:

https://github.com/apache/drill/pull/92#issuecomment-122968551
  
+1 LGTM


 Changing a session option to default value results in status as changed
 ---

 Key: DRILL-3122
 URL: https://issues.apache.org/jira/browse/DRILL-3122
 Project: Apache Drill
  Issue Type: Bug
  Components: Query Planning  Optimization
Affects Versions: 1.0.0
Reporter: Ramana Inukonda Nagaraj
Assignee: Jason Altekruse
 Fix For: 1.2.0

 Attachments: DRILL-3122.1.patch.txt


 Alter session option hash join to true(which is the default) and the 
 following query shows that the option has changed which could be misleading 
 to users relying on the status field to see if an option has changed or not. 
 Especially in the case of a boolean value. 
 {code}
 0: jdbc:drill:zk=10.10.100.171:5181 select * from sys.options where name 
 like '%hash%';
 ++--+-+--+-+-+---++
 |name|   kind   |  type   |  status  
 |   num_val   | string_val  | bool_val  | float_val  |
 ++--+-+--+-+-+---++
 | exec.max_hash_table_size   | LONG | SYSTEM  | DEFAULT  
 | 1073741824  | null| null  | null   |
 | exec.min_hash_table_size   | LONG | SYSTEM  | DEFAULT  
 | 65536   | null| null  | null   |
 | planner.enable_hash_single_key | BOOLEAN  | SYSTEM  | DEFAULT  
 | null| null| true  | null   |
 | planner.enable_hashagg | BOOLEAN  | SYSTEM  | DEFAULT  
 | null| null| true  | null   |
 | planner.enable_hashjoin| BOOLEAN  | SYSTEM  | DEFAULT  
 | null| null| true  | null   |
 | planner.enable_hashjoin_swap   | BOOLEAN  | SYSTEM  | DEFAULT  
 | null| null| true  | null   |
 | planner.join.hash_join_swap_margin_factor  | DOUBLE   | SYSTEM  | DEFAULT  
 | null| null| null  | 10.0   |
 | planner.memory.hash_agg_table_factor   | DOUBLE   | SYSTEM  | DEFAULT  
 | null| null| null  | 1.1|
 | planner.memory.hash_join_table_factor  | DOUBLE   | SYSTEM  | DEFAULT  
 | null| null| null  | 1.1|
 ++--+-+--+-+-+---++
 9 rows selected (0.191 seconds)
 0: jdbc:drill:zk=10.10.100.171:5181 alter session set 
 `planner.enable_hashjoin`=true;
 +---+---+
 |  ok   |  summary  |
 +---+---+
 | true  | planner.enable_hashjoin updated.  |
 +---+---+
 1 row selected (0.083 seconds)
 0: jdbc:drill:zk=10.10.100.171:5181 select * from sys.options where name 
 like '%hash%';
 ++--+--+--+-+-+---++
 |name|   kind   |   type   |  status  
 |   num_val   | string_val  | bool_val  | float_val  |
 ++--+--+--+-+-+---++
 | exec.max_hash_table_size   | LONG | SYSTEM   | DEFAULT  
 | 1073741824  | null| null  | null   |
 | exec.min_hash_table_size   | LONG | SYSTEM   | DEFAULT  
 | 65536   | null| null  | null   |
 | planner.enable_hash_single_key | BOOLEAN  | SYSTEM   | DEFAULT  
 | null| null| true  | null   |
 | planner.enable_hashagg | BOOLEAN  | SYSTEM   | DEFAULT  
 | null| null| true  | null   |
 | planner.enable_hashjoin| BOOLEAN  | SYSTEM   | DEFAULT  
 | null| null| true  | null   |
 | planner.enable_hashjoin| BOOLEAN  | SESSION  | CHANGED  
 | null| null| true  | null   |
 | planner.enable_hashjoin_swap   | BOOLEAN  | SYSTEM   | DEFAULT  
 | null| null| true  | null   |
 | planner.join.hash_join_swap_margin_factor  | DOUBLE   | SYSTEM   | DEFAULT  
 | null|

[jira] [Updated] (DRILL-3516) Improve UDF experience


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

Jacques Nadeau updated DRILL-3516:
--
Summary: Improve UDF experience  (was: UDF documentation doesn't get people 
where they need to be)

 Improve UDF experience
 --

 Key: DRILL-3516
 URL: https://issues.apache.org/jira/browse/DRILL-3516
 Project: Apache Drill
  Issue Type: Bug
Reporter: Ted Dunning

 Some users are finding the documentation at 
 http://drill.apache.org/docs/develop-custom-functions/ incomplete.  A 
 pertinent thread:
 http://mail-archives.apache.org/mod_mbox/drill-user/201507.mbox/%3CCACAwhF%3DBxs-bXNdrm0pNJ4e8hZiaueqtZMhJ%3DRiBpf%3Dt%3DzEOWA%40mail.gmail.com%3E



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

[jira] [Created] (DRILL-3519) Update UDFs to avoid requiring fully qualified class names

Jacques Nadeau created DRILL-3519:
-

 Summary: Update UDFs to avoid requiring fully qualified class names
 Key: DRILL-3519
 URL: https://issues.apache.org/jira/browse/DRILL-3519
 Project: Apache Drill
  Issue Type: Sub-task
  Components: Execution - Codegen
Reporter: Jacques Nadeau
Assignee: Chris Westin


Update the UDF processing subsystem so that it can rewrite inlined UDF code to 
leverage imports, removing the requirement to fully qualify external interface 
calls.



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

[jira] [Updated] (DRILL-3493) Alter session command with an option to cancel query in a particular phase of execution

2015-07-20 Thread Deneche A. Hakim (JIRA)


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

Deneche A. Hakim updated DRILL-3493:

Fix Version/s: 1.2.0

 Alter session command with an option to cancel query in a particular phase of 
 execution
 ---

 Key: DRILL-3493
 URL: https://issues.apache.org/jira/browse/DRILL-3493
 Project: Apache Drill
  Issue Type: New Feature
  Components: Execution - Flow
Reporter: Victoria Markman
Assignee: Deneche A. Hakim
Priority: Blocker
 Fix For: 1.2.0


 This proposal is to implement: 
 alter session cancel execution phase = true|false.
 where execution phase is an entry point for query cancellation, like say 
 sort or disk based sort , etc.
 When this option is set, if query reaches this point, forman would issue 
 cancel.
 This way: we can easily test correctness of query cancellation in different 
 types of queries.



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

[jira] [Updated] (DRILL-3521) [umbrella] Review switch statements throughout codebase to add default cases where there are none


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

Jason Altekruse updated DRILL-3521:
---
Fix Version/s: 1.3.0

 [umbrella] Review switch statements throughout codebase to add default cases 
 where there are none
 -

 Key: DRILL-3521
 URL: https://issues.apache.org/jira/browse/DRILL-3521
 Project: Apache Drill
  Issue Type: Bug
  Components: Execution - Flow
Reporter: Jason Altekruse
Assignee: Jason Altekruse
 Fix For: 1.3.0


 There are a number of places in the code that are missing default branches on 
 case statements. One particular instance I noticed is in 
 OptionValue.createOption, which returns null if passed an unexpected type. 
 This and a few other places in the code could be made a little nicer to work 
 with if we just provided the standard behavior of throwing an exception.
 One additional note, in a number of places where we do have defaults, but the 
 exception thrown is an UnsupportedOperationException with no message. 
 DRILL-2680 discusses this problem, so this might be handled over there, but 
 as we fill in the switch defaults we should try to avoid introducing the new 
 problem of exceptions lacking descriptions.



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

[jira] [Created] (DRILL-3521) [umbrella] Review switch statements throughout codebase to add default cases where there are none

Jason Altekruse created DRILL-3521:
--

 Summary: [umbrella] Review switch statements throughout codebase 
to add default cases where there are none
 Key: DRILL-3521
 URL: https://issues.apache.org/jira/browse/DRILL-3521
 Project: Apache Drill
  Issue Type: Bug
  Components: Execution - Flow
Reporter: Jason Altekruse
Assignee: Jason Altekruse


There are a number of places in the code that are missing default branches on 
case statements. One particular instance I noticed is in 
OptionValue.createOption, which returns null if passed an unexpected type. This 
and a few other places in the code could be made a little nicer to work with if 
we just provided the standard behavior of throwing an exception.

One additional note, in a number of places where we do have defaults, but the 
exception thrown is an UnsupportedOperationException with no message. 
DRILL-2680 discusses this problem, so this might be handled over there, but as 
we fill in the switch defaults we should try to avoid introducing the new 
problem of exceptions lacking descriptions.



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

[jira] [Commented] (DRILL-3520) Provide better logging around UDF loading and module loading

2015-07-20 Thread Daniel Barclay (Drill) (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633884#comment-14633884
 ] 

Daniel Barclay (Drill) commented on DRILL-3520:
---

This DRILL-3520 might be partly covered by DRILL-3496 logging improvements 
(e.g., logging detection of drill-module.conf files and the pattern of logging 
the finding of storage plug-ins, functions, etc.).

 Provide better logging around UDF loading and module loading
 

 Key: DRILL-3520
 URL: https://issues.apache.org/jira/browse/DRILL-3520
 Project: Apache Drill
  Issue Type: Sub-task
Reporter: Jacques Nadeau

 When adding an extension to Drill, sometimes it is hard to know what is going 
 on.  We should:
 - improve logging so that we report at INFO level information about all the 
 Jar files that were included in Drill's consideration set (marked) and those 
 that are not. (and include this debug analysis in the documentation)
 - If Drill fails to load a function, register an error function so that 
 trying to invoke the UDF will provide the user with information about why the 
 function failed to load.



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

[jira] [Updated] (DRILL-3521) [umbrella] Review switch statements throughout codebase to add default cases where there are none

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

Jason Altekruse updated DRILL-3521:
---
Description:
There are a number of places in the code that are missing default branches on
case statements. One particular instance I noticed is in
OptionValue.createOption, which returns null if passed an unexpected type. This
and a few other places in the code could be made a little nicer to work with if
we just provided the standard behavior of throwing an exception (or a
documented default value that will make sense in a few contexts).

One additional note, in a number of places where we do have defaults, but the
exception thrown is an UnsupportedOperationException with no message.
DRILL-2680 discusses this problem, so this might be handled over there, but as
we fill in the switch defaults we should try to avoid introducing the new
problem of exceptions lacking descriptions.

was:
There are a number of places in the code that are missing default branches on
case statements. One particular instance I noticed is in
OptionValue.createOption, which returns null if passed an unexpected type. This
and a few other places in the code could be made a little nicer to work with if
we just provided the standard behavior of throwing an exception.

[umbrella] Review switch statements throughout codebase to add default cases
where there are none
-

Key: DRILL-3521
URL: https://issues.apache.org/jira/browse/DRILL-3521
Project: Apache Drill
Issue Type: Bug
Components: Execution - Flow
Reporter: Jason Altekruse
Assignee: Jason Altekruse
Fix For: 1.3.0

There are a number of places in the code that are missing default branches on
case statements. One particular instance I noticed is in
OptionValue.createOption, which returns null if passed an unexpected type.
This and a few other places in the code could be made a little nicer to work
with if we just provided the standard behavior of throwing an exception (or a
documented default value that will make sense in a few contexts).
One additional note, in a number of places where we do have defaults, but the
exception thrown is an UnsupportedOperationException with no message.
DRILL-2680 discusses this problem, so this might be handled over there, but
as we fill in the switch defaults we should try to avoid introducing the new
problem of exceptions lacking descriptions.

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

[jira] [Created] (DRILL-3517) Add a UDF development FAQ

Jacques Nadeau created DRILL-3517:
-

 Summary: Add a UDF development FAQ
 Key: DRILL-3517
 URL: https://issues.apache.org/jira/browse/DRILL-3517
 Project: Apache Drill
  Issue Type: Sub-task
  Components: Documentation
Reporter: Jacques Nadeau
Assignee: Bridget Bevens


Lets create a UDF FAQ of common issues, log entries, etc so that people know 
what to do when they hit certain issues.



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

[jira] [Created] (DRILL-3518) Do a better job of providing conceptual overview to UDF creation

Jacques Nadeau created DRILL-3518:
-

 Summary: Do a better job of providing conceptual overview to UDF 
creation
 Key: DRILL-3518
 URL: https://issues.apache.org/jira/browse/DRILL-3518
 Project: Apache Drill
  Issue Type: Sub-task
  Components: Documentation
Reporter: Jacques Nadeau
Assignee: Bridget Bevens


Since UDFs are effectively written in Java, people find it confusing when some 
Java features aren't supported.  Let's try to do a better job of outlining the 
pitfalls.



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

[jira] [Created] (DRILL-3520) Provide better logging around UDF loading and module loading

Jacques Nadeau created DRILL-3520:
-

 Summary: Provide better logging around UDF loading and module 
loading
 Key: DRILL-3520
 URL: https://issues.apache.org/jira/browse/DRILL-3520
 Project: Apache Drill
  Issue Type: Sub-task
Reporter: Jacques Nadeau


When adding an extension to Drill, sometimes it is hard to know what is going 
on.  We should:

- improve logging so that we report at INFO level information about all the Jar 
files that were included in Drill's consideration set (marked) and those that 
are not. (and include this debug analysis in the documentation)
- If Drill fails to load a function, register an error function so that trying 
to invoke the UDF will provide the user with information about why the function 
failed to load.



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

[jira] [Updated] (DRILL-3193) TestDrillbitResilience#interruptingWhileFragmentIsBlockedInAcquiringSendingTicket hangs and fails

2015-07-20 Thread Sudheesh Katkam (JIRA)


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

Sudheesh Katkam updated DRILL-3193:
---
Fix Version/s: (was: 1.2.0)
   Future

 TestDrillbitResilience#interruptingWhileFragmentIsBlockedInAcquiringSendingTicket
  hangs and fails
 -

 Key: DRILL-3193
 URL: https://issues.apache.org/jira/browse/DRILL-3193
 Project: Apache Drill
  Issue Type: Bug
Reporter: Sudheesh Katkam
Assignee: Sudheesh Katkam
 Fix For: Future

 Attachments: 3193_thread_dump.txt


 TestDrillbitResilience#interruptingWhileFragmentIsBlockedInAcquiringSendingTicket
  hangs when it is run multiple times.



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

[jira] [Updated] (DRILL-3516) UDF documentation doesn't get people where they need to be


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

Jacques Nadeau updated DRILL-3516:
--
Description: 
Some users are finding the documentation at 
http://drill.apache.org/docs/develop-custom-functions/ incomplete.  A pertinent 
thread:

http://mail-archives.apache.org/mod_mbox/drill-user/201507.mbox/%3CCACAwhF%3DBxs-bXNdrm0pNJ4e8hZiaueqtZMhJ%3DRiBpf%3Dt%3DzEOWA%40mail.gmail.com%3E


  was:
The UDF documentation on the web side rooted at 
http://drill.apache.org/docs/develop-custom-functions/ does not describe the 
high level process for how UDF's are used, nor does it describe why simple 
things like toString can't work on *Holder data structures.

This leads to huge confusion and frustration on the part of potentially 
contributors.

Here are some pertinent threads:

http://mail-archives.apache.org/mod_mbox/drill-user/201507.mbox/%3CCACAwhF%3DBxs-bXNdrm0pNJ4e8hZiaueqtZMhJ%3DRiBpf%3Dt%3DzEOWA%40mail.gmail.com%3E

http://mail-archives.apache.org/mod_mbox/drill-user/201507.mbox/%3CCACAwhFmwWkP6udc05UEGFTzpEsaRvAxSRKW%2B2Mg-ijYX8QoQxQ%40mail.gmail.com%3E




 UDF documentation doesn't get people where they need to be
 --

 Key: DRILL-3516
 URL: https://issues.apache.org/jira/browse/DRILL-3516
 Project: Apache Drill
  Issue Type: Bug
Reporter: Ted Dunning

 Some users are finding the documentation at 
 http://drill.apache.org/docs/develop-custom-functions/ incomplete.  A 
 pertinent thread:
 http://mail-archives.apache.org/mod_mbox/drill-user/201507.mbox/%3CCACAwhF%3DBxs-bXNdrm0pNJ4e8hZiaueqtZMhJ%3DRiBpf%3Dt%3DzEOWA%40mail.gmail.com%3E



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

[jira] [Commented] (DRILL-3516) UDF documentation doesn't get people where they need to be


[ 
https://issues.apache.org/jira/browse/DRILL-3516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633744#comment-14633744
 ] 

Jacques Nadeau commented on DRILL-3516:
---

Notes from Stefan from Thread:

  - Source code needs to be included in the jar
   - it's used when the drillbits/queries are built/orchistrated

   - Always use full class qualifiers in the Eval() segment of your UDF

   - Don't forget to add the drill-module.conf to the resources folder of
   your project (should end up in th root of the jar)

   - Adding your udf package to drill-override.conf does not seem to matter
   - just copy the jar(s) with the .class and .java files to the
   jars/3rdparty directory

   - Feel free to user this code anyway you wish:
   - https://github.com/acmeguy/asdrill

   - Know about this project:
   - https://github.com/mapr-demos/simple-drill-functions

 UDF documentation doesn't get people where they need to be
 --

 Key: DRILL-3516
 URL: https://issues.apache.org/jira/browse/DRILL-3516
 Project: Apache Drill
  Issue Type: Bug
Reporter: Ted Dunning

 The UDF documentation on the web side rooted at 
 http://drill.apache.org/docs/develop-custom-functions/ does not describe the 
 high level process for how UDF's are used, nor does it describe why simple 
 things like toString can't work on *Holder data structures.
 This leads to huge confusion and frustration on the part of potentially 
 contributors.
 Here are some pertinent threads:
 http://mail-archives.apache.org/mod_mbox/drill-user/201507.mbox/%3CCACAwhF%3DBxs-bXNdrm0pNJ4e8hZiaueqtZMhJ%3DRiBpf%3Dt%3DzEOWA%40mail.gmail.com%3E
 http://mail-archives.apache.org/mod_mbox/drill-user/201507.mbox/%3CCACAwhFmwWkP6udc05UEGFTzpEsaRvAxSRKW%2B2Mg-ijYX8QoQxQ%40mail.gmail.com%3E



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

[jira] [Created] (DRILL-3516) UDF documentation doesn't get people where they need to be

Ted Dunning created DRILL-3516:
--

 Summary: UDF documentation doesn't get people where they need to be
 Key: DRILL-3516
 URL: https://issues.apache.org/jira/browse/DRILL-3516
 Project: Apache Drill
  Issue Type: Bug
Reporter: Ted Dunning


The UDF documentation on the web side rooted at 
http://drill.apache.org/docs/develop-custom-functions/ does not describe the 
high level process for how UDF's are used, nor does it describe why simple 
things like toString can't work on *Holder data structures.

This leads to huge confusion and frustration on the part of potentially 
contributors.

Here are some pertinent threads:

http://mail-archives.apache.org/mod_mbox/drill-user/201507.mbox/%3CCACAwhF%3DBxs-bXNdrm0pNJ4e8hZiaueqtZMhJ%3DRiBpf%3Dt%3DzEOWA%40mail.gmail.com%3E

http://mail-archives.apache.org/mod_mbox/drill-user/201507.mbox/%3CCACAwhFmwWkP6udc05UEGFTzpEsaRvAxSRKW%2B2Mg-ijYX8QoQxQ%40mail.gmail.com%3E





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

[jira] [Commented] (DRILL-3516) UDF documentation doesn't get people where they need to be


[ 
https://issues.apache.org/jira/browse/DRILL-3516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633745#comment-14633745
 ] 

Jacques Nadeau commented on DRILL-3516:
---

My notes to better provide the conceptual overview:

The key thing to understand is that a UDF is slightly incomplete Java.  This is 
because Drill actually rips apart the functionality of the UDF and recomposes 
it directly within expression evaluation code.  This gives a substantial 
performance and memory benefit but also creates some challenges.  As such, 
there are some key rules one should follow:
 
 - Don't use imports
 - Both class file and source file have to be on the classpath (yes, Drill uses 
the source of the function)
 - Any JAR files holding UDF resources must include drill-module.conf marker 
file so that Drill knows to include that JAR in consideration for UDF loading
 - ValueHolders should be treated as structs.  As such, don't call any methods 
on ValueHolders

 UDF documentation doesn't get people where they need to be
 --

 Key: DRILL-3516
 URL: https://issues.apache.org/jira/browse/DRILL-3516
 Project: Apache Drill
  Issue Type: Bug
Reporter: Ted Dunning

 The UDF documentation on the web side rooted at 
 http://drill.apache.org/docs/develop-custom-functions/ does not describe the 
 high level process for how UDF's are used, nor does it describe why simple 
 things like toString can't work on *Holder data structures.
 This leads to huge confusion and frustration on the part of potentially 
 contributors.
 Here are some pertinent threads:
 http://mail-archives.apache.org/mod_mbox/drill-user/201507.mbox/%3CCACAwhF%3DBxs-bXNdrm0pNJ4e8hZiaueqtZMhJ%3DRiBpf%3Dt%3DzEOWA%40mail.gmail.com%3E
 http://mail-archives.apache.org/mod_mbox/drill-user/201507.mbox/%3CCACAwhFmwWkP6udc05UEGFTzpEsaRvAxSRKW%2B2Mg-ijYX8QoQxQ%40mail.gmail.com%3E



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

[jira] [Commented] (DRILL-2815) Some PathScanner logging, misc. cleanup.


[ 
https://issues.apache.org/jira/browse/DRILL-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634143#comment-14634143
 ] 

Jason Altekruse commented on DRILL-2815:


[~dsbos] could you try to modify the PR title to include this JIRA number as 
well as DRILL-3496? It doesn't look like my commenting with the JIRA number 
actually
 linked the pull request to this bug report. So there are comments on github, 
they just haven't been copied here.

 Some PathScanner logging, misc. cleanup.
 

 Key: DRILL-2815
 URL: https://issues.apache.org/jira/browse/DRILL-2815
 Project: Apache Drill
  Issue Type: Bug
Reporter: Daniel Barclay (Drill)
Assignee: Daniel Barclay (Drill)
Priority: Minor
 Fix For: 1.2.0

 Attachments: DRILL-2815.5.patch.txt, DRILL-2815.6.patch.txt


 Add a little more  logging to PathScanner; clean up a little.



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

[jira] [Updated] (DRILL-3496) Augment logging in DrillConfig and classpath scanning.


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

Jason Altekruse updated DRILL-3496:
---
Assignee: Daniel Barclay (Drill)  (was: Jason Altekruse)

 Augment logging in DrillConfig and classpath scanning.
 --

 Key: DRILL-3496
 URL: https://issues.apache.org/jira/browse/DRILL-3496
 Project: Apache Drill
  Issue Type: Bug
Reporter: Daniel Barclay (Drill)
Assignee: Daniel Barclay (Drill)





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

[jira] [Updated] (DRILL-2815) Some PathScanner logging, misc. cleanup.


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

Jason Altekruse updated DRILL-2815:
---
Assignee: Daniel Barclay (Drill)  (was: Jason Altekruse)

 Some PathScanner logging, misc. cleanup.
 

 Key: DRILL-2815
 URL: https://issues.apache.org/jira/browse/DRILL-2815
 Project: Apache Drill
  Issue Type: Bug
Reporter: Daniel Barclay (Drill)
Assignee: Daniel Barclay (Drill)
Priority: Minor
 Fix For: 1.2.0

 Attachments: DRILL-2815.5.patch.txt, DRILL-2815.6.patch.txt


 Add a little more  logging to PathScanner; clean up a little.



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

[jira] [Commented] (DRILL-3341) Move OperatorWrapper list and FragmentWrapper list creation to ProfileWrapper ctor


[ 
https://issues.apache.org/jira/browse/DRILL-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634146#comment-14634146
 ] 

Jason Altekruse commented on DRILL-3341:


+1

 Move OperatorWrapper list and FragmentWrapper list creation to ProfileWrapper 
 ctor
 --

 Key: DRILL-3341
 URL: https://issues.apache.org/jira/browse/DRILL-3341
 Project: Apache Drill
  Issue Type: Improvement
Reporter: Sudheesh Katkam
Assignee: Jason Altekruse
Priority: Minor
 Fix For: 1.2.0

 Attachments: DRILL-3341.1.patch.txt, DRILL-3341.2.patch.txt


 + avoid re-computation in some cases
 + consistent comparator names



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

[jira] [Assigned] (DRILL-3067) Index out of bounds exception when in list contains exceeds 20 items and one of the items is a numeric expression

2015-07-20 Thread Sudheesh Katkam (JIRA)


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

Sudheesh Katkam reassigned DRILL-3067:
--

Assignee: Victoria Markman  (was: Sudheesh Katkam)

I don't see the errors anymore; I tried csv and parquet files. Can you repro 
now?

 Index out of bounds exception when in list contains exceeds 20 items and 
 one of the items is a numeric expression
 ---

 Key: DRILL-3067
 URL: https://issues.apache.org/jira/browse/DRILL-3067
 Project: Apache Drill
  Issue Type: Bug
  Components: Execution - Relational Operators
Affects Versions: 1.0.0
Reporter: Victoria Markman
Assignee: Victoria Markman
 Fix For: 1.2.0

 Attachments: in_list_integer.sql


 Index out of bounds exception when in list contains 10,000 integer values
 Failing query looks like this: select count(*) from t1 where a1 in (7680 
 integer values)
 drillbit.log
 {code}
 org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR: 
 java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
 Fragment 0:0
 [Error Id: 89dd9d30-ff0b-4513-bd79-624d63efb5f0 on atsqa4-133.qa.lab:31010]
 at 
 org.apache.drill.exec.work.foreman.QueryManager$1.statusUpdate(QueryManager.java:481)
  [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 org.apache.drill.exec.work.foreman.QueryManager$RootStatusReporter.statusChange(QueryManager.java:461)
  [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 org.apache.drill.exec.work.fragment.AbstractStatusReporter.fail(AbstractStatusReporter.java:90)
  [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 org.apache.drill.exec.work.fragment.AbstractStatusReporter.fail(AbstractStatusReporter.java:86)
  [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 org.apache.drill.exec.work.fragment.FragmentExecutor.sendFinalState(FragmentExecutor.java:291)
  [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:255)
  [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
  [drill-common-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  [na:1.7.0_71]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  [na:1.7.0_71]
 at java.lang.Thread.run(Thread.java:745) [na:1.7.0_71]
 2015-05-13 22:22:26,153 [2aac315d-a333-fa7d-3534-94912b01e07d:frag:0:0] INFO  
 o.a.d.e.w.fragment.FragmentExecutor - 
 2aac315d-a333-fa7d-3534-94912b01e07d:0:0: State change requested from FAILED 
 -- CANCELLATION_REQUESTED for
 2015-05-13 22:22:26,153 [2aac315d-a333-fa7d-3534-94912b01e07d:frag:0:0] WARN  
 o.a.d.e.w.fragment.FragmentExecutor - Ignoring unexpected state transition 
 FAILED = CANCELLATION_REQUESTED.
 2015-05-13 22:22:26,153 [2aac315d-a333-fa7d-3534-94912b01e07d:frag:0:0] INFO  
 o.a.drill.exec.work.foreman.Foreman - foreman cleaning up.
 2015-05-13 22:22:26,161 [2aac315d-a333-fa7d-3534-94912b01e07d:frag:0:0] ERROR 
 o.a.d.exec.work.foreman.QueryManager - Failure while storing Query Profile
 java.lang.RuntimeException: java.io.IOException: 
 java.lang.InterruptedException
 at 
 org.apache.drill.exec.store.sys.local.FilePStore.put(FilePStore.java:148) 
 ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 org.apache.drill.exec.work.foreman.QueryManager.writeFinalProfile(QueryManager.java:307)
  ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 org.apache.drill.exec.work.foreman.Foreman$ForemanResult.close(Foreman.java:743)
  [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:838)
  [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:780)
  [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 org.apache.drill.common.EventProcessor.sendEvent(EventProcessor.java:73) 
 [drill-common-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 org.apache.drill.exec.work.foreman.Foreman$StateSwitch.moveToState(Foreman.java:782)
  [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 org.apache.drill.exec.work.foreman.Foreman.moveToState(Foreman.java:891) 
 [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
 at 
 org.apache.drill.exec.work.foreman.Foreman.access$2700(Foreman.java:107)

[jira] [Comment Edited] (DRILL-3517) Add a UDF development FAQ


[ 
https://issues.apache.org/jira/browse/DRILL-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634309#comment-14634309
 ] 

Ted Dunning edited comment on DRILL-3517 at 7/21/15 1:44 AM:
-

8) My UDF is not a pure function so calling it with the same arguments will 
result in different values each time.  Drill is only using the result of 
calling my function once.  How can I fix that?

- Add the isRandom flag to the annotation that defines your class as a 
function:

 @FunctionTemplate(isRandom = true, ...)



was (Author: tdunning):

8) My UDF is not a pure function so calling it with the same arguments will 
result in different values each time.  Drill is only using the result of 
calling my function once.  How can I fix that?



 Add a UDF development FAQ
 -

 Key: DRILL-3517
 URL: https://issues.apache.org/jira/browse/DRILL-3517
 Project: Apache Drill
  Issue Type: Sub-task
  Components: Documentation
Reporter: Jacques Nadeau
Assignee: Bridget Bevens

 Lets create a UDF FAQ of common issues, log entries, etc so that people know 
 what to do when they hit certain issues.



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

[jira] [Commented] (DRILL-2818) Error message must be updated when query fails with FileNotFoundException


[ 
https://issues.apache.org/jira/browse/DRILL-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634221#comment-14634221
 ] 

ASF GitHub Bot commented on DRILL-2818:
---

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

https://github.com/apache/drill/pull/93#discussion_r35053796
  
--- Diff: 
common/src/main/java/org/apache/drill/common/logical/FormatPluginConfigBase.java
 ---
@@ -27,11 +27,20 @@
   static final org.slf4j.Logger logger = 
org.slf4j.LoggerFactory.getLogger(FormatPluginConfigBase.class);
 
 
-  public synchronized static Class?[] getSubTypes(DrillConfig config){
-ListString packages = 
config.getStringList(CommonConstants.STORAGE_PLUGIN_CONFIG_SCAN_PACKAGES);
-Class?[] sec = 
PathScanner.scanForImplementationsArr(FormatPluginConfig.class, packages);
-logger.debug(Adding Format Plugin Configs including {}, (Object) sec 
);
-return sec;
+  public synchronized static Class?[] getSubTypes(DrillConfig config) {
+ListString packages =
+
config.getStringList(CommonConstants.STORAGE_PLUGIN_CONFIG_SCAN_PACKAGES);
+Class?[] pluginClasses =
+PathScanner.scanForImplementationsArr(FormatPluginConfig.class, 
packages);
+if (logger.isDebugEnabled()) {
+  final StringBuilder sb = new StringBuilder();
--- End diff --

Yeah, I thought it should be factored out, but it wasn't clear where.   
(Also, the functionality is close to that of some utility join(...) 
methods--but not quite the same.)




 Error message must be updated when query fails with FileNotFoundException
 -

 Key: DRILL-2818
 URL: https://issues.apache.org/jira/browse/DRILL-2818
 Project: Apache Drill
  Issue Type: Bug
  Components: SQL Parser
Affects Versions: 0.9.0
 Environment: exception branch
Reporter: Abhishek Girish
Assignee: Deneche A. Hakim
Priority: Minor
  Labels: error_message_must_fix
 Fix For: 1.3.0


 When user specifies a non-existent file/directory in a query, the following 
 error is being thrown:
 {code:sql}
  show files from dfs.tmp.`tpch`;
 Query failed: SYSTEM ERROR: Failure handling SQL.
 [9184097e-8339-42d3-96ce-1fba51c6bc78 on 192.168.158.107:31010]
 Error: exception while executing query: Failure while executing query. 
 (state=,code=0)
 {code}
 This should be updated to 
 {code:sql}
  show files from dfs.tmp.`tpch`;
 Query failed: File /tmp/tpch does not exist. 
 {code}



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

[jira] [Commented] (DRILL-3364) Prune scan range if the filter is on the leading field with byte comparable encoding

2015-07-20 Thread Aditya Kishore (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634341#comment-14634341
 ] 

Aditya Kishore commented on DRILL-3364:
---

Are you able to run the new unit test successfully? I am getting the following 
exception

{noformat}
Running 
org.apache.drill.hbase.TestHBaseFilterPushDown#testFilterPushDownCompositeRowKey
Running query:
SELECT
 CONVERT_FROM(BYTE_SUBSTR(row_key, 1, 8), 'date_epoch_be') d
, CONVERT_FROM(BYTE_SUBSTR(row_key, 1, 8), 'bigint_be') ts
, CONVERT_FROM(BYTE_SUBSTR(row_key, 9, 8), 'bigint_be') id
, CONVERT_FROM(tableName.f.`USD`, 'int_be') price
 FROM hbase.`TestTableComposite` tableName
 WHERE
 CONVERT_FROM(row_key, 'date_epoch_be')  DATE '2015-06-18' AND
 CONVERT_FROM(BYTE_SUBSTR(row_key, 1, 8), 'date_epoch_be')  DATE '2015-06-13'
org.objectweb.asm.tree.analysis.AnalyzerException: Error at instruction 682: 
Expected an object reference, but found .
at org.objectweb.asm.tree.analysis.Analyzer.analyze(Analyzer.java:294)
at 
org.objectweb.asm.util.CheckMethodAdapter$1.visitEnd(CheckMethodAdapter.java:450)
at org.objectweb.asm.MethodVisitor.visitEnd(MethodVisitor.java:877)
at 
org.objectweb.asm.util.CheckMethodAdapter.visitEnd(CheckMethodAdapter.java:1028)
at org.objectweb.asm.MethodVisitor.visitEnd(MethodVisitor.java:877)
at 
org.apache.drill.exec.compile.CheckMethodVisitorFsm.visitEnd(CheckMethodVisitorFsm.java:114)
at org.objectweb.asm.MethodVisitor.visitEnd(MethodVisitor.java:877)
at 
org.apache.drill.exec.compile.CheckMethodVisitorFsm.visitEnd(CheckMethodVisitorFsm.java:114)
at org.objectweb.asm.MethodVisitor.visitEnd(MethodVisitor.java:877)
at org.objectweb.asm.MethodVisitor.visitEnd(MethodVisitor.java:877)
at 
org.apache.drill.exec.compile.bytecode.InstructionModifier.visitEnd(InstructionModifier.java:508)
at org.objectweb.asm.tree.MethodNode.accept(MethodNode.java:837)
at 
org.apache.drill.exec.compile.bytecode.ScalarReplacementNode.visitEnd(ScalarReplacementNode.java:87)
at org.objectweb.asm.MethodVisitor.visitEnd(MethodVisitor.java:877)
at 
org.apache.drill.exec.compile.bytecode.AloadPopRemover.visitEnd(AloadPopRemover.java:136)
at org.objectweb.asm.tree.MethodNode.accept(MethodNode.java:837)
at org.objectweb.asm.tree.MethodNode.accept(MethodNode.java:726)
at org.objectweb.asm.tree.ClassNode.accept(ClassNode.java:412)
at 
org.apache.drill.exec.compile.MergeAdapter.getMergedClass(MergeAdapter.java:223)
at 
org.apache.drill.exec.compile.ClassTransformer.getImplementationClass(ClassTransformer.java:265)
at 
org.apache.drill.exec.compile.CodeCompiler$Loader.load(CodeCompiler.java:80)
at 
org.apache.drill.exec.compile.CodeCompiler$Loader.load(CodeCompiler.java:76)
at 
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
at 
com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
at 
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
at 
com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
at 
org.apache.drill.exec.compile.CodeCompiler.getImplementationClass(CodeCompiler.java:65)
at 
org.apache.drill.exec.compile.CodeCompiler.getImplementationClass(CodeCompiler.java:58)
at 
org.apache.drill.exec.ops.FragmentContext.getImplementationClass(FragmentContext.java:299)
at 
org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.setupNewSchema(ProjectRecordBatch.java:442)
at 
org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:78)
at 
org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext(ProjectRecordBatch.java:129)
at 
org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:147)
at 
org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:118)
at 
org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:83)
at 
org.apache.drill.exec.physical.impl.ScreenCreator$ScreenRoot.innerNext(ScreenCreator.java:79)
at 
org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:73)
at 
org.apache.drill.exec.work.fragment.FragmentExecutor$1.run(FragmentExecutor.java:258)
at 
org.apache.drill.exec.work.fragment.FragmentExecutor$1.run(FragmentExecutor.java:252)
at java.security.AccessController.doPrivileged(Native Method)
at

[jira] [Commented] (DRILL-2601) Print SQL query text along with query id in drillbit.log

2015-07-20 Thread Khurram Faraaz (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634348#comment-14634348
 ] 

Khurram Faraaz commented on DRILL-2601:
---

It will be of great help if we print the SQL statement into drillbit.log
Especially useful when looking at drillbit.log and looking for a query that 
FAILED.

 Print SQL query text along with query id in drillbit.log
 

 Key: DRILL-2601
 URL: https://issues.apache.org/jira/browse/DRILL-2601
 Project: Apache Drill
  Issue Type: Improvement
  Components: Storage - Other
Reporter: Victoria Markman
Assignee: Sudheesh Katkam

 This is a request to print text of a query into drillbit.log  in the default 
 non verbose output. It includes all the changes of a session level parameters 
 and anything else that might help reproducing issue on a customer site.



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

[jira] [Updated] (DRILL-3503) Make PruneScanRule have a pluggable partitioning mechanism

2015-07-20 Thread Mehant Baid (JIRA)


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

Mehant Baid updated DRILL-3503:
---
Attachment: DRILL-3503_part2.patch
DRILL-3503_part1.patch

First patch is a minor formatting patch generated automatically using IDE. 
Second patch is the actual change.

 Make PruneScanRule have a pluggable partitioning mechanism
 --

 Key: DRILL-3503
 URL: https://issues.apache.org/jira/browse/DRILL-3503
 Project: Apache Drill
  Issue Type: Bug
Reporter: Mehant Baid
Assignee: Mehant Baid
 Fix For: 1.2.0

 Attachments: DRILL-3503_part1.patch, DRILL-3503_part2.patch


 Currently PruneScanRule performs partition pruning for file system. Some of 
 the code relies on certain aspects of how partitioning is done in DFS. This 
 JIRA aims to abstract out the behavior of the underlying partition scheme and 
 delegate to the specific storage plugin to get that information. 



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

[jira] [Commented] (DRILL-3364) Prune scan range if the filter is on the leading field with byte comparable encoding

2015-07-20 Thread Smidth Panchamia (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634368#comment-14634368
 ] 

Smidth Panchamia commented on DRILL-3364:
-

Oh, let me test it out and update the change. Thanks!

 Prune scan range if the filter is on the leading field with byte comparable 
 encoding
 

 Key: DRILL-3364
 URL: https://issues.apache.org/jira/browse/DRILL-3364
 Project: Apache Drill
  Issue Type: Sub-task
  Components: Storage - HBase
Reporter: Aditya Kishore
Assignee: Smidth Panchamia
 Fix For: 1.2.0

 Attachments: composite.jun26.diff






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

[jira] [Commented] (DRILL-3364) Prune scan range if the filter is on the leading field with byte comparable encoding

2015-07-20 Thread Aditya Kishore (JIRA)


[ 
https://issues.apache.org/jira/browse/DRILL-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634369#comment-14634369
 ] 

Aditya Kishore commented on DRILL-3364:
---

Thanks. When you update the patch, could you please use git's mailbox format[1].


[1] http://git-scm.com/docs/git-format-patch

 Prune scan range if the filter is on the leading field with byte comparable 
 encoding
 

 Key: DRILL-3364
 URL: https://issues.apache.org/jira/browse/DRILL-3364
 Project: Apache Drill
  Issue Type: Sub-task
  Components: Storage - HBase
Reporter: Aditya Kishore
Assignee: Smidth Panchamia
 Fix For: 1.2.0

 Attachments: composite.jun26.diff






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

[jira] [Updated] (DRILL-3503) Make PruneScanRule have a pluggable partitioning mechanism

2015-07-20 Thread Mehant Baid (JIRA)


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

Mehant Baid updated DRILL-3503:
---
Assignee: Aman Sinha  (was: Mehant Baid)

 Make PruneScanRule have a pluggable partitioning mechanism
 --

 Key: DRILL-3503
 URL: https://issues.apache.org/jira/browse/DRILL-3503
 Project: Apache Drill
  Issue Type: Bug
Reporter: Mehant Baid
Assignee: Aman Sinha
 Fix For: 1.2.0

 Attachments: DRILL-3503_part1.patch, DRILL-3503_part2.patch


 Currently PruneScanRule performs partition pruning for file system. Some of 
 the code relies on certain aspects of how partitioning is done in DFS. This 
 JIRA aims to abstract out the behavior of the underlying partition scheme and 
 delegate to the specific storage plugin to get that information. 



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

[jira] [Commented] (DRILL-2818) Error message must be updated when query fails with FileNotFoundException


[ 
https://issues.apache.org/jira/browse/DRILL-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634201#comment-14634201
 ] 

ASF GitHub Bot commented on DRILL-2818:
---

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

https://github.com/apache/drill/pull/93#discussion_r35052980
  
--- Diff: 
common/src/main/java/org/apache/drill/common/config/DrillConfig.java ---
@@ -138,34 +155,77 @@ public static DrillConfig create(Properties 
testConfigurations) {
 return create(null, testConfigurations, true);
   }
 
-  public static DrillConfig create(String overrideFileName, boolean 
enableServerConfigs) {
-return create(overrideFileName, null, enableServerConfigs);
+  /**
+   * ...
+   * @param overrideFileResourcePathname
+   *  see {@link #create(String)}'s {@code 
overrideFileResourcePathname}
+   */
+  public static DrillConfig create(String overrideFileResourcePathname, 
boolean enableServerConfigs) {
+return create(overrideFileResourcePathname, null, enableServerConfigs);
   }
 
-  private static DrillConfig create(String overrideFileName, Properties 
overriderProps, boolean enableServerConfigs) {
-overrideFileName = overrideFileName == null ? 
CommonConstants.CONFIG_OVERRIDE : overrideFileName;
-
-// first we load defaults.
+  /**
+   * ...
+   * @param overrideFileResourcePathname
+   *  see {@link #create(String)}'s {@code 
overrideFileResourcePathname}
+   * @param overriderProps
+   *  optional property map for further overriding (after override 
file
+   *  is assimilated
+   * @param enableServerConfigs
+   *  whether to enable server-specific configuration options
+   * @return
+   */
+  private static DrillConfig create(String overrideFileResourcePathname,
+final Properties overriderProps,
+final boolean enableServerConfigs) {
+overrideFileResourcePathname =
+overrideFileResourcePathname == null
+? CommonConstants.CONFIG_OVERRIDE
+: overrideFileResourcePathname;
+
+// 1. Load defaults configuration file.
 Config fallback = null;
 final ClassLoader[] classLoaders = ClasspathHelper.classLoaders();
 for (ClassLoader classLoader : classLoaders) {
-  if (classLoader.getResource(CommonConstants.CONFIG_DEFAULT) != null) 
{
-fallback = ConfigFactory.load(classLoader, 
CommonConstants.CONFIG_DEFAULT);
+  final URL url =
+  classLoader.getResource(CommonConstants.CONFIG_DEFAULT);
+  if (null != url) {
+logger.debug(Loading base config. file at {}., url);
+fallback =
+ConfigFactory.load(classLoader,
+   CommonConstants.CONFIG_DEFAULT);
 break;
   }
 }
 
+// 2. Load per-module configuration files.
 CollectionURL urls = PathScanner.getConfigURLs();
 logger.debug(Loading configs at the following URLs {}, urls);
 for (URL url : urls) {
+  logger.debug(Loading module config. file at {}., url);
   fallback = ConfigFactory.parseURL(url).withFallback(fallback);
 }
 
-Config effectiveConfig = 
ConfigFactory.load(overrideFileName).withFallback(fallback);
+// 3. Load any overrides configuration file and overrides from JVM
--- End diff --

Reworded a bit.


 Error message must be updated when query fails with FileNotFoundException
 -

 Key: DRILL-2818
 URL: https://issues.apache.org/jira/browse/DRILL-2818
 Project: Apache Drill
  Issue Type: Bug
  Components: SQL Parser
Affects Versions: 0.9.0
 Environment: exception branch
Reporter: Abhishek Girish
Assignee: Deneche A. Hakim
Priority: Minor
  Labels: error_message_must_fix
 Fix For: 1.3.0


 When user specifies a non-existent file/directory in a query, the following 
 error is being thrown:
 {code:sql}
  show files from dfs.tmp.`tpch`;
 Query failed: SYSTEM ERROR: Failure handling SQL.
 [9184097e-8339-42d3-96ce-1fba51c6bc78 on 192.168.158.107:31010]
 Error: exception while executing query: Failure while executing query. 
 (state=,code=0)
 {code}
 This should be updated to 
 {code:sql}
  show files from dfs.tmp.`tpch`;
 Query failed: File /tmp/tpch does not exist. 
 {code}



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

[jira] [Commented] (DRILL-2818) Error message must be updated when query fails with FileNotFoundException


[ 
https://issues.apache.org/jira/browse/DRILL-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634214#comment-14634214
 ] 

ASF GitHub Bot commented on DRILL-2818:
---

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

https://github.com/apache/drill/pull/93#discussion_r35053589
  
--- Diff: 
common/src/main/java/org/apache/drill/common/config/DrillConfig.java ---
@@ -115,19 +124,26 @@ public static DrillConfig forClient() {
* p
* Configuration values are retrieved as follows:
* ul
-   * liCheck a single copy of drill-override.conf. If multiple copies 
are on the classpath, behavior is
-   * indeterminate.  If a non-null value for overrideFileName is provided, 
this is utilized instead of drill-override.conf./li
-   * liCheck all copies of drill-module.conf. Loading order is 
indeterminate./li
-   * liCheck a single copy of drill-default.conf. If multiple copies 
are on the classpath, behavior is
-   * indeterminate./li
+   * liCheck a single copy of drill-override.conf.  If multiple copies 
are
+   * on the classpath, which copy is read is indeterminate.
+   * If a non-null value for overrideFileResourcePathname is provided, 
this
+   * is used instead of {@code drill-override.conf}./li
+   * liCheck all copies of {@code drill-module.conf}.  Loading order is
+   * indeterminate./li
+   * liCheck a single copy of {@code drill-default.conf}.  If multiple
+   * copies are on the classpath, which copy is read is 
indeterminate./li
* /ul
*
* /p
-   *  @param overrideFileName The name of the file to use for override 
purposes.
+   * @param overrideFileResourcePathname
+   *  the classpath resource pathname of the file to use for
+   *  configuration override purposes; {@code null} specifies to 
use the
+   *  default pathname ({@link CommonConstants.CONFIG_OVERRIDE})
+   *  (strongnot/strong to not look for an override file at 
all)
--- End diff --

Reworded.


 Error message must be updated when query fails with FileNotFoundException
 -

 Key: DRILL-2818
 URL: https://issues.apache.org/jira/browse/DRILL-2818
 Project: Apache Drill
  Issue Type: Bug
  Components: SQL Parser
Affects Versions: 0.9.0
 Environment: exception branch
Reporter: Abhishek Girish
Assignee: Deneche A. Hakim
Priority: Minor
  Labels: error_message_must_fix
 Fix For: 1.3.0


 When user specifies a non-existent file/directory in a query, the following 
 error is being thrown:
 {code:sql}
  show files from dfs.tmp.`tpch`;
 Query failed: SYSTEM ERROR: Failure handling SQL.
 [9184097e-8339-42d3-96ce-1fba51c6bc78 on 192.168.158.107:31010]
 Error: exception while executing query: Failure while executing query. 
 (state=,code=0)
 {code}
 This should be updated to 
 {code:sql}
  show files from dfs.tmp.`tpch`;
 Query failed: File /tmp/tpch does not exist. 
 {code}



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

[jira] [Commented] (DRILL-3518) Do a better job of providing conceptual overview to UDF creation


[ 
https://issues.apache.org/jira/browse/DRILL-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634262#comment-14634262
 ] 

Ted Dunning commented on DRILL-3518:


Pitfalls I have fallen into:

1) All data that a UDF uses must be annotated and must be a type that the 
annotation accepts

2) All class references must be fully qualified

3) It is super-easy to make a UDF that doesn't actually load and it is hard to 
see why (at first)

4) UDAF's can't have complex @Workspace variables because there seems to be no 
way to allocate even a Repeated* value, much less to have a ComplexWriter in 
the @Workspace

5) The annotated input, workspace and output variables have life-cycles that 
aren't apparent from the lexical structure of a UDAF. The fact that at add time 
the add() method can't see the output and that at output time both workspace 
and output variables are visible is confusing.

6) figuring out the maven-fu to create acceptable jars takes quite a while



 Do a better job of providing conceptual overview to UDF creation
 

 Key: DRILL-3518
 URL: https://issues.apache.org/jira/browse/DRILL-3518
 Project: Apache Drill
  Issue Type: Sub-task
  Components: Documentation
Reporter: Jacques Nadeau
Assignee: Bridget Bevens

 Since UDFs are effectively written in Java, people find it confusing when 
 some Java features aren't supported.  Let's try to do a better job of 
 outlining the pitfalls.



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

[jira] [Commented] (DRILL-2818) Error message must be updated when query fails with FileNotFoundException


[ 
https://issues.apache.org/jira/browse/DRILL-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634191#comment-14634191
 ] 

ASF GitHub Bot commented on DRILL-2818:
---

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

https://github.com/apache/drill/pull/93#discussion_r35052392
  
--- Diff: 
common/src/main/java/org/apache/drill/common/config/DrillConfig.java ---
@@ -90,7 +97,8 @@ public DrillConfig(Config config, boolean enableServer) {
   }
 
   /**
-   * Create a DrillConfig object using the default config file name
+   * Creates a DrillConfig object using the default config file name
+   * and with server-specific configuration options disabled.
--- End diff --

Fixed.


 Error message must be updated when query fails with FileNotFoundException
 -

 Key: DRILL-2818
 URL: https://issues.apache.org/jira/browse/DRILL-2818
 Project: Apache Drill
  Issue Type: Bug
  Components: SQL Parser
Affects Versions: 0.9.0
 Environment: exception branch
Reporter: Abhishek Girish
Assignee: Deneche A. Hakim
Priority: Minor
  Labels: error_message_must_fix
 Fix For: 1.3.0


 When user specifies a non-existent file/directory in a query, the following 
 error is being thrown:
 {code:sql}
  show files from dfs.tmp.`tpch`;
 Query failed: SYSTEM ERROR: Failure handling SQL.
 [9184097e-8339-42d3-96ce-1fba51c6bc78 on 192.168.158.107:31010]
 Error: exception while executing query: Failure while executing query. 
 (state=,code=0)
 {code}
 This should be updated to 
 {code:sql}
  show files from dfs.tmp.`tpch`;
 Query failed: File /tmp/tpch does not exist. 
 {code}



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

[jira] [Commented] (DRILL-2818) Error message must be updated when query fails with FileNotFoundException


[ 
https://issues.apache.org/jira/browse/DRILL-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634206#comment-14634206
 ] 

ASF GitHub Bot commented on DRILL-2818:
---

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

https://github.com/apache/drill/pull/93#discussion_r35053195
  
--- Diff: 
common/src/main/java/org/apache/drill/common/config/DrillConfig.java ---
@@ -44,31 +46,37 @@
 import com.google.common.collect.ImmutableList;
 import com.typesafe.config.Config;
 import com.typesafe.config.ConfigFactory;
+import com.typesafe.config.ConfigRenderOptions;
 
 public final class DrillConfig extends NestedConfig{
-//  private static final org.slf4j.Logger logger = 
org.slf4j.LoggerFactory.getLogger(DrillConfig.class);
+  private static final Logger logger = getLogger(DrillConfig.class);
+
   private final ObjectMapper mapper;
   private final ImmutableListString startupArguments;
 
   public static final boolean ON_OSX = 
System.getProperty(os.name).contains(OS X);
 
-  @SuppressWarnings(restriction)  private static final long 
MAX_DIRECT_MEMORY = sun.misc.VM.maxDirectMemory();
+  @SuppressWarnings(restriction)
+  private static final long MAX_DIRECT_MEMORY = 
sun.misc.VM.maxDirectMemory();
 
   @SuppressWarnings(unchecked)
   private volatile ListQueueObject sinkQueues = new 
CopyOnWriteArrayListQueueObject(new Queue[1]);
 
   @VisibleForTesting
-  public DrillConfig(Config config, boolean enableServer) {
+  public DrillConfig(Config config, boolean enableServerConfigs) {
 super(config);
-logger.debug(Setting up config object.);
+logger.debug(Setting up DrillConfig object.);
+if (logger.isTraceEnabled()) {
--- End diff --

No, I didn't expect it to take any significant time; I just thought someone 
would object if the calls weren't guarded by that if statement.

So ... remove it to reduce the clutter, or keep/leave it?


 Error message must be updated when query fails with FileNotFoundException
 -

 Key: DRILL-2818
 URL: https://issues.apache.org/jira/browse/DRILL-2818
 Project: Apache Drill
  Issue Type: Bug
  Components: SQL Parser
Affects Versions: 0.9.0
 Environment: exception branch
Reporter: Abhishek Girish
Assignee: Deneche A. Hakim
Priority: Minor
  Labels: error_message_must_fix
 Fix For: 1.3.0


 When user specifies a non-existent file/directory in a query, the following 
 error is being thrown:
 {code:sql}
  show files from dfs.tmp.`tpch`;
 Query failed: SYSTEM ERROR: Failure handling SQL.
 [9184097e-8339-42d3-96ce-1fba51c6bc78 on 192.168.158.107:31010]
 Error: exception while executing query: Failure while executing query. 
 (state=,code=0)
 {code}
 This should be updated to 
 {code:sql}
  show files from dfs.tmp.`tpch`;
 Query failed: File /tmp/tpch does not exist. 
 {code}



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

[jira] [Commented] (DRILL-2818) Error message must be updated when query fails with FileNotFoundException


[ 
https://issues.apache.org/jira/browse/DRILL-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634239#comment-14634239
 ] 

ASF GitHub Bot commented on DRILL-2818:
---

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

https://github.com/apache/drill/pull/93#discussion_r35054916
  
--- Diff: 
common/src/main/java/org/apache/drill/common/config/DrillConfig.java ---
@@ -138,34 +154,83 @@ public static DrillConfig create(Properties 
testConfigurations) {
 return create(null, testConfigurations, true);
   }
 
-  public static DrillConfig create(String overrideFileName, boolean 
enableServerConfigs) {
-return create(overrideFileName, null, enableServerConfigs);
+  /**
+   * ...
+   * @param overrideFileResourcePathname
+   *  see {@link #create(String)}'s {@code 
overrideFileResourcePathname}
+   */
+  public static DrillConfig create(String overrideFileResourcePathname, 
boolean enableServerConfigs) {
+return create(overrideFileResourcePathname, null, enableServerConfigs);
   }
 
-  private static DrillConfig create(String overrideFileName, Properties 
overriderProps, boolean enableServerConfigs) {
-overrideFileName = overrideFileName == null ? 
CommonConstants.CONFIG_OVERRIDE : overrideFileName;
-
-// first we load defaults.
+  /**
+   * ...
--- End diff --

[Reply via e-mail because I don't currently see this comment of yours on 
the pull-request page.]

  +  /**
  +   * ...xx

  I haven't seen this convention before, but I assume this means that the 
docs for similar methods suffice and don't need to be repeated here.

No, actually it was an attempt to indicate that I hadn't addressed the 
method description (the part before the parameters), and not intended to mean 
otherwise same as above.

I was trying to quickly at least document the parameter (add the reference 
to the other existing text) without taking time to fill in the whole 
documentation comment.

Would simply leaving the method description part blank be better than using 
...?

Daniel





Jason Altekruse wrote:

 In common/src/main/java/org/apache/drill/common/config/DrillConfig.java 
https://github.com/apache/drill/pull/93#discussion_r35042277:

 }
 
  -  private static DrillConfig create(String overrideFileName, 
Properties overriderProps, boolean enableServerConfigs) {
  -overrideFileName = overrideFileName == null ? 
CommonConstants.CONFIG_OVERRIDE : overrideFileName;
  -
  -// first we load defaults.
  +  /**
  +   * ...

 I haven't seen this convention before, but I assume this means that the 
docs for similar methods suffice and don't need to be repeated here. I would 
possibly recommend moving the longer comment above to here, in which case I 
think it would be possible to just put ... above all of the alternative 
implementations of this method. I think it makes the most sense to put the 
comment describing the general idea of the functions purpose above the version 
that also describes what all of parameters can do.

 —
 Reply to this email directly or view it on GitHub 
https://github.com/apache/drill/pull/93/files#r35042277.



-- 
Daniel Barclay
MapR Technologies




 Error message must be updated when query fails with FileNotFoundException
 -

 Key: DRILL-2818
 URL: https://issues.apache.org/jira/browse/DRILL-2818
 Project: Apache Drill
  Issue Type: Bug
  Components: SQL Parser
Affects Versions: 0.9.0
 Environment: exception branch
Reporter: Abhishek Girish
Assignee: Deneche A. Hakim
Priority: Minor
  Labels: error_message_must_fix
 Fix For: 1.3.0


 When user specifies a non-existent file/directory in a query, the following 
 error is being thrown:
 {code:sql}
  show files from dfs.tmp.`tpch`;
 Query failed: SYSTEM ERROR: Failure handling SQL.
 [9184097e-8339-42d3-96ce-1fba51c6bc78 on 192.168.158.107:31010]
 Error: exception while executing query: Failure while executing query. 
 (state=,code=0)
 {code}
 This should be updated to 
 {code:sql}
  show files from dfs.tmp.`tpch`;
 Query failed: File /tmp/tpch does not exist. 
 {code}



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

[jira] [Commented] (DRILL-3517) Add a UDF development FAQ


[ 
https://issues.apache.org/jira/browse/DRILL-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634253#comment-14634253
 ] 

Ted Dunning commented on DRILL-3517:


Let's start in these comments:

1) Drill UDF's are not run in the lexical environment that you might think
  1.a) imports will just confuse you
  1.b) all class references need to be fully qualified
  1.c) fields that you define will get left behind

2) Inputs and outputs have to be in *Holder types

3) complex outputs can be created using the ComplexWriter

4) you need to build both source and binary jars.  Examples available


Not sure if these are FAQ format anymore.


 Add a UDF development FAQ
 -

 Key: DRILL-3517
 URL: https://issues.apache.org/jira/browse/DRILL-3517
 Project: Apache Drill
  Issue Type: Sub-task
  Components: Documentation
Reporter: Jacques Nadeau
Assignee: Bridget Bevens

 Lets create a UDF FAQ of common issues, log entries, etc so that people know 
 what to do when they hit certain issues.



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

[jira] [Commented] (DRILL-3517) Add a UDF development FAQ


[ 
https://issues.apache.org/jira/browse/DRILL-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634258#comment-14634258
 ] 

Ted Dunning commented on DRILL-3517:


More in the line of FAQ's:

1) my UDF didn't get loaded.  What happened?
- see the log
- you probably have a subtle error related to the lexical environment

2) my UDF got loaded, but didn't get used.  What happened?
- you may not have the right types/may need more type variants

3) Is there an example of a simple transforming UDF?

4) Is there a sample of a UDAF?

5) How can I use my own types as temporary data in my UDAF?

6) I defined fields in my class that implements a UDF, but I get a compile 
error that says that they are undefined.  Heh?

7) How can I see the generated code that includes my UDF?



 Add a UDF development FAQ
 -

 Key: DRILL-3517
 URL: https://issues.apache.org/jira/browse/DRILL-3517
 Project: Apache Drill
  Issue Type: Sub-task
  Components: Documentation
Reporter: Jacques Nadeau
Assignee: Bridget Bevens

 Lets create a UDF FAQ of common issues, log entries, etc so that people know 
 what to do when they hit certain issues.



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

[jira] [Commented] (DRILL-3520) Provide better logging around UDF loading and module loading


[ 
https://issues.apache.org/jira/browse/DRILL-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634267#comment-14634267
 ] 

Ted Dunning commented on DRILL-3520:



I think that the function logging should become much more extensive if there 
are any functions that fail to load.  A list of jars that had failed functions, 
a list that were loaded without error and so on would be very helpful, as would 
a dump of the classpath.  The volume of logging isn't a big deal since this is 
a one-off that only occurs when things are borked.




 Provide better logging around UDF loading and module loading
 

 Key: DRILL-3520
 URL: https://issues.apache.org/jira/browse/DRILL-3520
 Project: Apache Drill
  Issue Type: Sub-task
Reporter: Jacques Nadeau

 When adding an extension to Drill, sometimes it is hard to know what is going 
 on.  We should:
 - improve logging so that we report at INFO level information about all the 
 Jar files that were included in Drill's consideration set (marked) and those 
 that are not. (and include this debug analysis in the documentation)
 - If Drill fails to load a function, register an error function so that 
 trying to invoke the UDF will provide the user with information about why the 
 function failed to load.



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

[jira] [Commented] (DRILL-3517) Add a UDF development FAQ