My observation on this, as a newcomer, is that it is a paradoxical for a
build to fail on extra space in a meaningful javadoc, but not on the
actual missing text, @param, @see or a @return sections on the public
methods.
On many classes there is no javadoc at all. On some, it is invalid.
This mak
Long story short (sorry :-|) - does it make sense to have a build stopping
check for \s+$ in a javadoc and not check and stop the build for missing or
improper javadoc?
On Thursday, September 10, 2015, Edmon Begoli wrote:
> My observation on this, as a newcomer, is that it is a paradoxical for a
My proposal:
1) Loosen checks between 1.2 and 1.3 releases
2) let me and as many other people as they are willing to contribute effort
to add proper javadoc.
Ask any contributor touching methods to add few lines of missing javadoc
3) once done tighten up the build to the max enforcing all best s
Hey Edmon,
I completely agree that Checkstyle can be a pain. I've worked on a couple
projects where the rules are truly draconian. In Drill today, I think we
have only the following rules:
1) No trailing whitespace
2) No If statements without brackets (other than ternary)
3) No imports of the wro
Since most editors and IDEs will strip trailing whitespace everywhere in a
file (code or comments), we should leave it in to avoid getting spurious
diffs.
On Thu, Sep 10, 2015 at 7:02 AM, Jacques Nadeau wrote:
> Hey Edmon,
>
> I completely agree that Checkstyle can be a pain. I've worked on a co
My opinion is to keep trailing spaces checks in as they are.
On Thursday, September 10, 2015, Jacques Nadeau wrote:
> Hey Edmon,
>
> I completely agree that Checkstyle can be a pain. I've worked on a couple
> projects where the rules are truly draconian. In Drill today, I think we
> have only th
On Thu, Sep 10, 2015 at 7:02 AM, Jacques Nadeau wrote:
> I think that the trailing
> whitespace check does provide great use in code so I'd prefer to keep it.
>
> What do you think?
>
I think that we should have a rule that every class should have javadoc on
the class.
Github user amansinha100 commented on a diff in the pull request:
https://github.com/apache/drill/pull/151#discussion_r39176878
--- Diff:
contrib/storage-hive/core/src/main/java/org/apache/drill/exec/planner/sql/HivePartitionDescriptor.java
---
@@ -62,7 +62,7 @@ public
HivePartit
Github user vkorukanti commented on a diff in the pull request:
https://github.com/apache/drill/pull/151#discussion_r39177644
--- Diff:
contrib/storage-hive/core/src/main/java/org/apache/drill/exec/planner/sql/HivePartitionDescriptor.java
---
@@ -62,7 +62,7 @@ public
HivePartitio
Victoria Markman created DRILL-3758:
---
Summary: InvalidRecorException while selecting from a table with
multiple parquet file
Key: DRILL-3758
URL: https://issues.apache.org/jira/browse/DRILL-3758
Pro
Github user asfgit closed the pull request at:
https://github.com/apache/drill/pull/151
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabl
[
https://issues.apache.org/jira/browse/DRILL-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Venki Korukanti resolved DRILL-3746.
Resolution: Fixed
> Hive query fails if the table contains external partitions
> ---
I believe the usage of Semi-Join had been proposed before.
Would that new operator help in this scenario you think?
On Wed, Sep 9, 2015 at 8:16 PM, Jinfeng Ni wrote:
> The reason that the in-list join approach is not fast enough :
> the query has 5 in-lists ORed together. Each in-list is conver
Github user jinfengni commented on a diff in the pull request:
https://github.com/apache/drill/pull/152#discussion_r39189463
--- Diff:
exec/java-exec/src/test/java/org/apache/drill/exec/TestWindowFunctions.java ---
@@ -165,49 +258,182 @@ public void testWindowGroupByOnView() throws
Github user jinfengni commented on the pull request:
https://github.com/apache/drill/pull/152#issuecomment-139324948
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled
Github user sudheeshkatkam commented on a diff in the pull request:
https://github.com/apache/drill/pull/152#discussion_r39192041
--- Diff: exec/java-exec/src/test/java/org/apache/drill/BaseTestQuery.java
---
@@ -379,6 +379,16 @@ protected static void parseErrorHelper(final String
I think Semi-join is not valid in this case, since the original query
has 5 in-lists ORed together. If Semi-join is used, then the rows
that does not qualify for the first 1 in-list filter would be pruned out,
which is not valid, since they may qualify for the second in-list filter.
That's why lef
Github user sudheeshkatkam commented on a diff in the pull request:
https://github.com/apache/drill/pull/120#discussion_r39193558
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/work/fragment/FragmentManager.java
---
@@ -38,36 +37,43 @@
* @return True if the f
Github user jinfengni commented on a diff in the pull request:
https://github.com/apache/drill/pull/120#discussion_r39193879
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/work/fragment/FragmentManager.java
---
@@ -38,36 +37,43 @@
* @return True if the fragme
Github user sudheeshkatkam commented on a diff in the pull request:
https://github.com/apache/drill/pull/120#discussion_r39194893
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/work/fragment/FragmentManager.java
---
@@ -38,36 +37,43 @@
* @return True if the f
[
https://issues.apache.org/jira/browse/DRILL-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristine Hahn resolved DRILL-3645.
--
Resolution: Fixed
Fix Version/s: 1.2.0
Fix has been published
> typo in drill documentat
Github user cwestin commented on a diff in the pull request:
https://github.com/apache/drill/pull/120#discussion_r39196959
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/work/fragment/FragmentManager.java
---
@@ -38,36 +37,43 @@
* @return True if the fragment
Github user cwestin commented on a diff in the pull request:
https://github.com/apache/drill/pull/120#discussion_r39197169
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/vector/BitVector.java ---
@@ -211,8 +220,11 @@ public TransferPair makeTransferPair(ValueVector to
Hi,
Querying nested data from a JSON file with and with out setting
store.json.all_text_mode
results in errors.
Data that was used in the test is available here -
https://data.cityofchicago.org/Health-Human-Services/Food-Inspections/4ijn-s7e5
There is an option (on the top right) to Export as
Github user hsuanyi commented on the pull request:
https://github.com/apache/drill/pull/152#issuecomment-139341107
Addressed jinfengni and sudheeshkatkam 's comments, Thanks!!!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as w
Github user hsuanyi commented on a diff in the pull request:
https://github.com/apache/drill/pull/152#discussion_r39198057
--- Diff: exec/java-exec/src/test/java/org/apache/drill/BaseTestQuery.java
---
@@ -379,6 +379,16 @@ protected static void parseErrorHelper(final String
testSq
Github user hsuanyi commented on the pull request:
https://github.com/apache/drill/pull/152#issuecomment-139341626
Will report after done with the tests
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
Aman Sinha created DRILL-3759:
-
Summary: Make partition pruning multi-phased to reduce the working
set kept in memory
Key: DRILL-3759
URL: https://issues.apache.org/jira/browse/DRILL-3759
Project: Apache
Can we cartesian-join all the values in the in list and rewrite it as a
single in list:
For example,
Say, the original where-clause is
"a in (1, 2) or b in (3, 4)"
Can we implement a rule to let calcite treat it as
"(a, b) in ((1,3),(1,4),(2,3),(2,4))"
-
Wait... that transformation works for AND but not for OR...
On Thu, Sep 10, 2015 at 1:12 PM, Hsuan Yi Chu wrote:
> Can we cartesian-join all the values in the in list and rewrite it as a
> single in list:
>
> For example,
> Say, the original where-clause is
>
> "a in (1, 2) or b in (3, 4)"
>
> C
Github user cwestin commented on the pull request:
https://github.com/apache/drill/pull/105#issuecomment-139377475
I added code to collect errors, as well as to interrupt the test thread
when an error occurs.
---
If your project is set up for it, you can reply to this email and have
Daniel Barclay (Drill) created DRILL-3760:
-
Summary: Casting interval to string and back to interval fails
Key: DRILL-3760
URL: https://issues.apache.org/jira/browse/DRILL-3760
Project: Apache
Github user jinfengni commented on a diff in the pull request:
https://github.com/apache/drill/pull/120#discussion_r39214700
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/vector/BitVector.java ---
@@ -211,8 +220,11 @@ public TransferPair makeTransferPair(ValueVector
This is a known issue, we have been describing this schema change scenario
as a change in "data shape". Here is a very simple dataset that will
produce the same error
{ "a" : 1 }
{ "a" : { "b" : 3} }
We currently only use all_text_mode to change the type of the data at a
leaf in the schema.
Ther
Github user sudheeshkatkam commented on a diff in the pull request:
https://github.com/apache/drill/pull/105#discussion_r39214895
--- Diff:
exec/java-exec/src/test/java/org/apache/drill/TestTpchDistributedConcurrent.java
---
@@ -0,0 +1,206 @@
+/**
+ * Licensed to the Apach
Github user sudheeshkatkam commented on a diff in the pull request:
https://github.com/apache/drill/pull/105#discussion_r39214988
--- Diff:
exec/java-exec/src/test/java/org/apache/drill/TestTpchDistributedConcurrent.java
---
@@ -0,0 +1,177 @@
+/**
+ * Licensed to the Apach
Github user cwestin commented on a diff in the pull request:
https://github.com/apache/drill/pull/105#discussion_r39216243
--- Diff:
exec/java-exec/src/test/java/org/apache/drill/TestTpchDistributedConcurrent.java
---
@@ -0,0 +1,206 @@
+/**
+ * Licensed to the Apache Softw
Github user cwestin commented on a diff in the pull request:
https://github.com/apache/drill/pull/105#discussion_r39216415
--- Diff:
exec/java-exec/src/test/java/org/apache/drill/TestTpchDistributedConcurrent.java
---
@@ -0,0 +1,177 @@
+/**
+ * Licensed to the Apache Softw
Jinfeng Ni created DRILL-3761:
-
Summary: CastIntDecimal implementation should not update the input
holder.
Key: DRILL-3761
URL: https://issues.apache.org/jira/browse/DRILL-3761
Project: Apache Drill
It's interesting that the following query also fails:
SELECT COUNT(meta) FROM `rows.json`
the schema change is nested inside meta.view, so even though we are
counting how many meta "groups" we have, Drill still reads and materializes
all the content of the meta field.
On Thu, Sep 10, 2015 at 2
Khurram Faraaz created DRILL-3762:
-
Summary: NPE : Query nested JSON data
Key: DRILL-3762
URL: https://issues.apache.org/jira/browse/DRILL-3762
Project: Apache Drill
Issue Type: Bug
Github user asfgit closed the pull request at:
https://github.com/apache/drill/pull/120
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabl
Github user cwestin commented on the pull request:
https://github.com/apache/drill/pull/105#issuecomment-139409971
Addressed Sudheesh's comments. Unless Jason has anything else, can we
please get this merged now?
---
If your project is set up for it, you can reply to this email and h
Agree on the N phased approach. I have filed a JIRA for the enhancement:
DRILL-3759.
Regarding the simplification of the expression tree logic..did you mean the
logic in FindPartitionConditions or the Interpreter ?
Perhaps you can add comments in the JIRA with some explanation. I am in
favor of
Seems to me one important reason we hit out of heap memory for partition
prune rule is that the rule itself is invoked multiple times, even the
filter has been pushed into scan in the first call.
I tried with a simple unit
test TestPartitionFilter:testPartitionFilter1_Parquet_from_CTAS(), here is
Khurram Faraaz created DRILL-3763:
-
Summary: Cancel (Ctrl-C) one of concurrent queries results in
ChannelClosedException
Key: DRILL-3763
URL: https://issues.apache.org/jira/browse/DRILL-3763
Project:
Aman Sinha created DRILL-3764:
-
Summary: Support the ability to identify and/or skip records when
a function evaluation fails
Key: DRILL-3764
URL: https://issues.apache.org/jira/browse/DRILL-3764
Project:
GitHub user jinfengni opened a pull request:
https://github.com/apache/drill/pull/153
Drill 3754: Remove redundancy in run-time generated code for common column
references
Test done:
unit test
pre-commit test.
You can merge this pull request into a Git repository by
Jinfeng Ni created DRILL-3765:
-
Summary: Partition prune rule is unnecessary fired multiple times.
Key: DRILL-3765
URL: https://issues.apache.org/jira/browse/DRILL-3765
Project: Apache Drill
Iss
I opened DRILL-3765 for the multiple rule execution issue:
https://issues.apache.org/jira/browse/DRILL-3765
On Thu, Sep 10, 2015 at 5:34 PM, Jinfeng Ni wrote:
> Seems to me one important reason we hit out of heap memory for partition
> prune rule is that the rule itself is invoked multiple time
Ted Dunning wrote:
...
I think that we should have a rule that every class should have javadoc on
the class.
Since it will take a long time to get to that state, we should
probably start with whichever are the most important classes to
document.
That fuzzy set of "most important" classes proba
Yes, it is a good point about multiple invocations of the PruneScan rule.
The other point about using Java heap is not correct. The rule does
off-heap allocation using memory buffer from QueryContext and in the
finally block releases the memory.
Aman
On Thu, Sep 10, 2015 at 6:18 PM, Jinfeng Ni
I haven't looked at your patch yet. Do you try to address the issue where
we do redundant retrieval for all situations or only for some. Seems like
it should be managed at the class generator level since it could have this
context.
Also note that you probably would see a substantial benefit if you
I got the impression of Java heap memory because one customer
complained about running into out of heap memory, when they are
dealing with pruning large number of files. Is it possible that the rule
put the value vector in the direct memory, but also uses object reference
which is proportional to t
It is an easy fix for javadoc, and it has been approved by Jacques:
https://github.com/apache/drill/pull/139
Thank you,
Edmon
I will open an issue and work on this proposed javadoc.
I am a "first principles" type of person, and I do not see myself being
able to effectively do stuff until I understand the Drill API inside-out
myself.
A result of the learning process should be contributed back to the project.
I'll start w
Github user asfgit closed the pull request at:
https://github.com/apache/drill/pull/152
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabl
Github user sudipmukherjee closed the pull request at:
https://github.com/apache/drill/pull/138
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
58 matches
Mail list logo