date:20181011

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

2018-10-11 Thread ASF GitHub Bot (JIRA)



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

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

KazydubB commented on issue #1496: DRILL-6783: CAST string literal as INTERVAL 
MONTH/YEAR works inconsis…
URL: https://github.com/apache/drill/pull/1496#issuecomment-428848036
 
 
   @vvysotskyi, I've added a unit test, please take a look.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



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

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

2018-10-11 Thread Volodymyr Vysotskyi (JIRA)



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

Volodymyr Vysotskyi updated DRILL-6783:
---
Labels: ready-to-commit  (was: )

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



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

[jira] [Commented] (DRILL-5332) DateVector support uses questionable conversions to a time

2018-10-11 Thread Vitalii Diravka (JIRA)



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

Vitalii Diravka commented on DRILL-5332:


Actually {{DateVector}} was changed in the DRILL-6242, but not sure that solved 
the current issue. For now it looks like 
[this|https://github.com/apache/drill/blob/master/exec/vector/src/main/codegen/templates/FixedValueVectors.java#L537]:
{code}
@Override
public LocalDate getObject(int index) {
  return LocalDateTime.ofInstant(Instant.ofEpochMilli(get(index)), 
ZoneOffset.UTC).toLocalDate();
}
{code}
It still uses UTC timeZone. 
Possibly it can be return statement could be replaced with 
{code}
return LocalDate.ofEpochDay(get(index));
{code}
[~paul-rogers] Does it make sense?

> DateVector support uses questionable conversions to a time
> --
>
> Key: DRILL-5332
> URL: https://issues.apache.org/jira/browse/DRILL-5332
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Priority: Major
>
> The following code in {{DateVector}} is worrisome:
> {code}
> @Override
> public DateTime getObject(int index) {
> org.joda.time.DateTime date = new org.joda.time.DateTime(get(index), 
> org.joda.time.DateTimeZone.UTC);
> date = 
> date.withZoneRetainFields(org.joda.time.DateTimeZone.getDefault());
> return date;
> }
> {code}
> This code takes a date/time value stored in a value vector, converts it to 
> UTC, then strips the time zone and replaces it with local time. The result it 
> a "timestamp" in Java format (seconds since the epoch), but not really, it 
> really the time since the epoch, as if the epoch had started in the local 
> time zone rather than UTC.
> This is the kind of fun & games that people used to do in Java with the 
> {{Date}}  type before the advent of Joda time (and the migration of Joda into 
> Java 8.)
> It is, in short, very bad practice and nearly impossible to get right.
> Further, converting a pure date (since this is a {{DateVector}}) into a 
> date/time is fraught with peril. A date has no corresponding time. 1 AM on 
> Friday in one time zone might be 11 PM on Thursday in another. Converting 
> from dates to times is very difficult.
> If the {{DateVector}} corresponds to a date, then it should be simple date 
> with no implied time zone and no implied relationship to time. If there is to 
> be a mapping of time, it must be to a {{LocalTime}} (in Joda and Java 8) that 
> has no implied time zone.
> Note that this code directly contradicts the statement in [Drill 
> documentation|http://drill.apache.org/docs/date-time-and-timestamp/]: "Drill 
> stores values in Coordinated Universal Time (UTC)." Actually, even the 
> documentation is questionable: what does it mean to store a date in UTC 
> because of the above issues?



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

[jira] [Commented] (DRILL-5334) Questionable code in the TimeVector class

2018-10-11 Thread Vitalii Diravka (JIRA)



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

Vitalii Diravka commented on DRILL-5334:


Actually after DRILL-6242 _TimeVector_ uses Java8 _LocalDateTime_ based on 
_java.time.Instant_ and _UTC_ timezone, consequently with using _ZoneOffset_.
https://github.com/apache/drill/blob/master/exec/vector/src/main/codegen/templates/FixedValueVectors.java#L537
If get(index) return millis per day, probably the following code can be used:
{code}return LocalTime.ofNanoOfDay(millisOfDay * NANOS_PER_MILLIS);
{code}

> Questionable code in the TimeVector class
> -
>
> Key: DRILL-5334
> URL: https://issues.apache.org/jira/browse/DRILL-5334
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Priority: Major
>
> The {{TimeVector}} class, which holds Time data, should hold a simple local 
> time with no associated date or time zone. (A local time cannot be converted 
> to UTC without a date since the conversion depends on when daylight savings 
> is in effect.)
> But, the implementation of {{TimeVector}} uses the following very 
> questionable code:
> {code}
> @Override
> public DateTime getObject(int index) {
> org.joda.time.DateTime time = new org.joda.time.DateTime(get(index), 
> org.joda.time.DateTimeZone.UTC);
> time = 
> time.withZoneRetainFields(org.joda.time.DateTimeZone.getDefault());
> return time;
> }
> {code}
> That is, we convert a date-less, local time into a Joda UTC DateTime object, 
> then reset the time zone to local time. This is abusing the Joda library and 
> is the very kind of fun & games that Joda was designed to prevent.
> The conversion of a time into Joda should use the {{LocalTime}} class.
> In fact, according to 
> [Oracle|http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html],
>  the following is the mapping from ANSI SQL date/time types to Java 8 (and 
> thus Joda) classes:
> ||ANSI SQL||Java SE 8
> |DATE|LocalDate
> |TIME|LocalTime
> |TIMESTAMP|LocalDateTime
> |TIME WITH TIMEZONE|OffsetTime
> |TIMESTAMP WITH TIMEZONE|OffsetDateTime



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

[jira] [Commented] (DRILL-3988) Create a sys.functions table to expose available Drill functions

2018-10-11 Thread ASF GitHub Bot (JIRA)



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

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

arina-ielchiieva commented on a change in pull request #1483: DRILL-3988: 
Expose Drill built-in functions & UDFs  in a system table
URL: https://github.com/apache/drill/pull/1483#discussion_r224387658
 
 

 ##
 File path: 
exec/java-exec/src/test/java/org/apache/drill/exec/expr/fn/registry/FunctionRegistryHolderTest.java
 ##
 @@ -155,6 +162,47 @@ public void testGetAllJarNames() {
 compareTwoLists(expectedResult, registryHolder.getAllJarNames());
   }
 
+  @Test
+  public void testGetAllJarsWithFunctionHolders() {
+Map> fnHoldersInRegistry = 
registryHolder.getAllJarsWithFunctionHolders();
+//Iterate and confirm lists are same
+for (String jarName : newJars.keySet()) {
+  List expectedHolderList = newJars.get(jarName).stream()
+  .map(FunctionHolder::getHolder) //Extract DrillFuncHolder
+  .collect(Collectors.toList());
+  List testHolderList = 
fnHoldersInRegistry.get(jarName).stream()
+  .map(FunctionHolder::getHolder) //Extract DrillFuncHolder
+  .collect(Collectors.toList());
+
+  compareTwoLists(expectedHolderList, testHolderList);
+}
+
+Map shuffleFunctionMap = new HashMap<>();
+// Confirm that same function spans multiple jars with different signatures
+//Init: Expected Map of items
+for (String jarName : newJars.keySet()) {
+  for (FunctionHolder funcHolder : newJars.get(jarName)) {
+if (funcHolder.getName().equals(SHUFFLE_FUNC_NAME)) {
 
 Review comment:
   General recommendation is not use equals on constant to avoid NPE: 
`SHUFFLE_FUNC_NAME.equals(funcHolder.getName())`. Please change here and in the 
code below.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create a sys.functions table to expose available Drill functions
> 
>
> Key: DRILL-3988
> URL: https://issues.apache.org/jira/browse/DRILL-3988
> Project: Apache Drill
>  Issue Type: Sub-task
>  Components: Metadata
>Reporter: Jacques Nadeau
>Assignee: Kunal Khatua
>Priority: Major
>  Labels: doc-impacting
> Fix For: 1.15.0
>
>
> Create a new sys.functions table that returns a list of all available 
> functions.
> Key considerations: 
> - one row per name or one per argument set. I'm inclined to latter so people 
> can use queries to get to data.
> - we need to create a delineation between user functions and internal 
> functions and only show user functions. 'CastInt' isn't something the user 
> should be able to see (or run).
> - should we add a description annotation that could be included in the 
> sys.functions table?



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

[jira] [Comment Edited] (DRILL-6741) CircleCI for Drill

2018-10-11 Thread Vitalii Diravka (JIRA)



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

Vitalii Diravka edited comment on DRILL-6741 at 10/11/18 10:02 AM:
---

[~timothyfarkas] I have opened 
[PR-1493|https://github.com/apache/drill/pull/1493] tor the first sub-task. 
Could you please review it?

Also I have created sub-tasks how it is possible to improve CircleCI build for 
Drill in future.
 To enable CircleCI for Drill it is necessary to merge the PR and possibly to 
make the similar request as we made for Travis: INFRA-7372


was (Author: vitalii):
[~timothyfarkas] I have opened 
[PR-1493|https://github.com/apache/drill/pull/1493] tor the first sub-task. 
Could you please review it? 

Also I have created sub-tasks how it is possible to improve CircleCI build for 
Drill in future.
To enable CircleCI for Drill it is necessary to merge the PR and possibly to 
make the similar request as we made for GitBox: INFRA-16411

> CircleCI for Drill
> --
>
> Key: DRILL-6741
> URL: https://issues.apache.org/jira/browse/DRILL-6741
> Project: Apache Drill
>  Issue Type: Test
>  Components: Tools, Build & Test
>Affects Versions: 1.14.0
>Reporter: Vitalii Diravka
>Assignee: Vitalii Diravka
>Priority: Major
> Fix For: 1.15.0
>
>
> There is a discussion regarding usage of CircleCI for Drill:
>  
> [https://lists.apache.org/thread.html/4d8cfa074dd427ac4d495f8767752f9be1ce95cc82c51f767f7611e4@%3Cdev.drill.apache.org%3E]
> Current issue is limit of RAM for Docker images: 4Gb, but 8Gb is needed.
>  Can be solved by using of CircleCI VM, the RAM limit in this case is 8Gb.
> Besides that I am looking to ask CircleCI team about providing {{large}} 
> {{resource_class}} for dcoker images:
> https://circleci.com/docs/2.0/configuration-reference/#resource_class 



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

[jira] [Commented] (DRILL-6776) Drill Web UI takes long time for first time load in network isolated environment

2018-10-11 Thread ASF GitHub Bot (JIRA)



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

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

arina-ielchiieva closed pull request #1495: DRILL-6776: Drill Web UI takes long 
time for first time load in network isolated environment
URL: https://github.com/apache/drill/pull/1495
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/exec/java-exec/src/main/resources/rest/generic.ftl 
b/exec/java-exec/src/main/resources/rest/generic.ftl
index 81204f795c1..5b2dc45568c 100644
--- a/exec/java-exec/src/main/resources/rest/generic.ftl
+++ b/exec/java-exec/src/main/resources/rest/generic.ftl
@@ -35,9 +35,7 @@
 
   
 
-  
-   window.jQuery  || document.write('