Re: log flooded by "date values definitively CORRECT"

Thanks for your input. After investigation, we essentially fixed the issue by re-adjusting the size of the parquet files we generate. Bigger files, less of them. It was interesting to explore the extreme limit in term of number of files and how it impacts a single foreman at planning time. Good

[GitHub] drill pull request #997: DRILL-5882: C++ Client: [Threat Modeling] Drillbit ...

Github user asfgit closed the pull request at: https://github.com/apache/drill/pull/997 ---

[GitHub] drill pull request #999: DRILL-5881:Java Client: [Threat Modeling] Drillbit ...

Github user asfgit closed the pull request at: https://github.com/apache/drill/pull/999 ---

[GitHub] drill issue #999: DRILL-5881:Java Client: [Threat Modeling] Drillbit may be ...

Github user parthchandra commented on the issue: https://github.com/apache/drill/pull/999 +1 to the second commit as well. This addresses the problem of the unit tests failing intermittently. ---

[GitHub] drill pull request #984: DRILL-5783 Made a unit test for generated Priority ...

Github user ilooner commented on a diff in the pull request: https://github.com/apache/drill/pull/984#discussion_r145827440 --- Diff: exec/java-exec/src/test/java/org/apache/drill/TestAltSortQueries.java --- @@ -64,9 +73,9 @@ public void testJoinWithLimit() throws Exception{

[jira] [Created] (DRILL-5894) A Storage plugin called dfs_test is added in unit tests. It's actually unnecessary and we should just use dfs

Timothy Farkas created DRILL-5894: - Summary: A Storage plugin called dfs_test is added in unit tests. It's actually unnecessary and we should just use dfs Key: DRILL-5894 URL:

[GitHub] drill pull request #984: DRILL-5783 Made a unit test for generated Priority ...

Github user ilooner commented on a diff in the pull request: https://github.com/apache/drill/pull/984#discussion_r145815670 --- Diff: exec/java-exec/src/test/resources/topN/one_key_sort.json --- @@ -12,11 +12,11 @@ pop:"mock-scan", url:

Re: Excessive review comments

Going back to one comment by Paul : “The only other solution is to give few review comments; not sure if we want to go that route...” IMO the individual code review comments should be concise such that the main idea is expressed. This is more palatable for the original developer and he/she can

[GitHub] drill pull request #984: DRILL-5783 Made a unit test for generated Priority ...

Github user ilooner commented on a diff in the pull request: https://github.com/apache/drill/pull/984#discussion_r145790506 --- Diff: exec/vector/src/main/codegen/templates/FixedValueVectors.java --- @@ -908,6 +908,15 @@ public void generateTestData(int count) { }

[GitHub] drill issue #1003: DRILL-5893: Reverted the number of forked test processes ...

Github user ilooner commented on the issue: https://github.com/apache/drill/pull/1003 @arina-ielchiieva ---

Re: Excessive review comments

To subscribe to PRs and JIRAs of interest, we need to know about them first. Is it possible to get notified when a new PR or JIRA is created and not for further updates unless you subscribe to them ? Thanks Padma > On Oct 19, 2017, at 10:13 AM, Paul Rogers wrote: > > So,

[GitHub] drill pull request #1003: DRILL-5893: Reverted the number of forked test pro...

GitHub user ilooner opened a pull request: https://github.com/apache/drill/pull/1003 DRILL-5893: Reverted the number of forked test processes back to 2 You can merge this pull request into a Git repository by running: $ git pull https://github.com/ilooner/drill DRILL-5893

[jira] [Created] (DRILL-5893) Maven forkCount property is too aggressive causing builds to fail on some machines.

Timothy Farkas created DRILL-5893: - Summary: Maven forkCount property is too aggressive causing builds to fail on some machines. Key: DRILL-5893 URL: https://issues.apache.org/jira/browse/DRILL-5893

Re: Excessive review comments

I would prefer a solution that does not require subscribing to individual PRs or JIRAs. How would one know what is interesting if one doesn't get notified? On Thu, Oct 19, 2017 at 10:13 AM, Paul Rogers wrote: > So, rather than copying all messages to dev, simply ask interested

Re: describe query support? (catalog metadata, etc)

Hi Alfredo, When I was trying to get Drill to work with various BI tools, all I really needed was a list of columns. Data types would be a big bonus, but Drill interprets CSV data as plain text anyway. It would be really useful for other file types where Drill does infer data types. — C

[GitHub] drill pull request #970: DRILL-5832: Migrate OperatorFixture to use SystemOp...

Github user ilooner commented on a diff in the pull request: https://github.com/apache/drill/pull/970#discussion_r145764765 --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/store/parquet2/DrillParquetReader.java --- @@ -331,21 +320,21 @@ public int next() {

[GitHub] drill pull request #970: DRILL-5832: Migrate OperatorFixture to use SystemOp...

Github user ilooner commented on a diff in the pull request: https://github.com/apache/drill/pull/970#discussion_r145764035 --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/store/dfs/FileSelection.java --- @@ -208,17 +208,17 @@ public boolean wasAllPartitionsPruned()

[GitHub] drill pull request #970: DRILL-5832: Migrate OperatorFixture to use SystemOp...

Github user ilooner commented on a diff in the pull request: https://github.com/apache/drill/pull/970#discussion_r145766449 --- Diff: exec/java-exec/src/test/java/org/apache/drill/exec/physical/impl/writer/TestParquetWriter.java --- @@ -725,21 +724,24 @@ public void

[GitHub] drill pull request #970: DRILL-5832: Migrate OperatorFixture to use SystemOp...

Github user ilooner commented on a diff in the pull request: https://github.com/apache/drill/pull/970#discussion_r145766019 --- Diff: exec/java-exec/src/test/java/org/apache/drill/BaseTestQuery.java --- @@ -371,6 +373,16 @@ public static void testNoResult(String query, Object...

[GitHub] drill pull request #970: DRILL-5832: Migrate OperatorFixture to use SystemOp...

Github user ilooner commented on a diff in the pull request: https://github.com/apache/drill/pull/970#discussion_r145762743 --- Diff: contrib/storage-hive/core/src/test/java/org/apache/drill/exec/hive/TestHiveStorage.java --- @@ -74,10 +73,8 @@ public void

Re: Excessive review comments

So, rather than copying all messages to dev, simply ask interested folks subscribe to the PRs of interest. (Or, subscribe to the corresponding JIRA tickets, since JIRA echos all comments in another spray of e-mail…) This way, semi-active folks on the dev list can see substantive discussions

Re: Excessive review comments

I generally keep track of dev activity only through the emails sent. I don't mind getting duplicate emails either - it's not too hard to write a filter to take out the stuff you're not interested in. Interestingly, I've never noticed whether 'start a review' sends one email or many; mostly

Re: Excessive review comments

+1 for turning off the feature. If someone really needs to be emailed with comment updates they can become a watcher of the repo on Github. From: Paul Rogers Sent: Thursday, October 19, 2017 9:43:26 AM To: dev@drill.apache.org Subject: Re:

Re: Excessive review comments

Can we simply turn off the feature? I never, ever read the e-mails coming from this source; I always follow the link back to the PR. Can we reduce it to “Hey, just wanted to let you know that a new comment was posted. Click _here_ to read it.” The only other solution is to give few review

[GitHub] drill issue #1002: DRILL-5888: Remove dependency of SSLConfig on hadoop.secu...

Github user parthchandra commented on the issue: https://github.com/apache/drill/pull/1002 Thanks Arina. I removed the unused imports. ---

[GitHub] drill pull request #1001: JIRA DRILL-5879: Like operator performance improve...

Github user sachouche commented on a diff in the pull request: https://github.com/apache/drill/pull/1001#discussion_r145746250 --- Diff: exec/java-exec/src/main/codegen/templates/CastFunctionsSrcVarLenTargetVarLen.java --- @@ -73,6 +73,9 @@ public void eval() { out.start

Re: Excessive review comments

Agree, I am not sure I saw this feature working as well. All it did it was sending all the emails at once, rather in the process of comments emergence. Kind regards Arina On Thu, Oct 19, 2017 at 6:27 PM, Julian Hyde wrote: > I don’t know whether anything is broken. I believed

Re: Excessive review comments

I don’t know whether anything is broken. I believed that the GitHub “start a review” feature would cause all review comments to be sent in a single email. But now I think of it, I’m not sure I ever saw it working. I wonder whether Github-ASF integration is at fault. Whatever the reasons for

[GitHub] drill pull request #998: DRILL-5887: Display process user/groups info in Dri...

Github user arina-ielchiieva commented on a diff in the pull request: https://github.com/apache/drill/pull/998#discussion_r145686885 --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/DrillRoot.java --- @@ -85,19 +86,24 @@ public ClusterInfo