date:20150701

[jira] [Commented] (DRILL-3152) Apache Drill 1.0 not able to query MongoDB 3.0.

2015-07-01 Thread Bhallamudi Venkata Siva Kamesh (JIRA)


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

Bhallamudi Venkata Siva Kamesh commented on DRILL-3152:
---

bq. Error: SYSTEM ERROR: java.lang.IllegalArgumentException: You tried to write 
a VarChar type when you are using a ValueWriter of type 
NullableTimeStampWriterImpl.
By looking at the exception, I think,  one or some of the columns may contains 
values from different data types. Could you please check, all the values  from 
each column are of the same data type?



 Apache Drill 1.0 not able to query MongoDB 3.0. 
 

 Key: DRILL-3152
 URL: https://issues.apache.org/jira/browse/DRILL-3152
 Project: Apache Drill
  Issue Type: Bug
  Components: Storage - MongoDB
Affects Versions: 0.9.0, 1.0.0
 Environment: The environment is as follows:
 Windows 7
 MongoDB 3 Wiredtiger (installed locally)
 Apache Drill 1.0 (installed locally)
Reporter: Trent Telfer
Assignee: B Anil Kumar
  Labels: mongodb, mongodb3, windows7, wiredtiger

 I have been trying to get Apache Drill 1.0, and previously 0.9 to work with 
 MongoDB 3.0 Wiredtiger. I have no problem starting Apache Drill using the 
 following, but I am having problems querying MongoDB:
 *./sqlline.bat*
 *!connect jdbc:drill:zk=local*
 *SHOW DATABASES;*
 +-+
 | SCHEMA_NAME |
 +-+
 | INFORMATION_SCHEMA  |
 | cp.default  |
 | dfs.default |
 | dfs.root|
 | dfs.tmp |
 | mongo.admin |
 | mongo.alliance_db   |
 | mongo.local |
 | sys |
 +-+
 *USE mongo.alliance_db;*
 +---++
 |  ok   |summary |
 +---++
 | true  | Default schema changed to [mongo.alliance_db]  |
 +---++
 1 row selected (0.116 seconds)
 *SELECT * FROM price_daily_ngi;*
 May 20, 2015 11:14:40 AM 
 org.apache.calcite.sql.validate.SqlValidatorException init
 SEVERE: org.apache.calcite.sql.validate.SqlValidatorException: Table 
 'price_daily_ngi' not found
 May 20, 2015 11:14:40 AM org.apache.calcite.runtime.CalciteException init
 SEVERE: org.apache.calcite.runtime.CalciteContextException: From line 1, 
 column 15 to line 1, column 29: Table 'price_daily_ngi' not found
 Error: PARSE ERROR: From line 1, column 15 to line 1, column 29: Table 
 'price_daily_ngi' not found
 [Error Id: 6414a69d-55a0-4918-8f95-10a920e4dc6b on PCV:31010] (state=,code=0)
 MongoDB storage configuration:
 {
   type: mongo,
   connection: mongodb://localhost:27017,
   enabled: true
 }
 The collection price_daily_ngi exists and works with normal MongoDB queries.



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

[jira] [Commented] (DRILL-3435) Some reserved-keywords require table aliasing

2015-07-01 Thread Kristine Hahn (JIRA)


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

Kristine Hahn commented on DRILL-3435:
--

[~bbevens] How about we change:

FROM:
In other table references, aliases are optional.

TO:
Aliases might be required for querying nested JSON. Aliases are definitely 
required resolve ambiguous references, such as using the name user to query 
the Drill profiles. Drill treats user as a function in this case, and the 
returns unexpected results. If you use a table alias, Drill treats user as a 
column identifier, and the query returns expected results.

[~bbevens] Is there somewhere in your profile querying doc where the bit about 
using user should be mentioned?

 Some reserved-keywords require table aliasing
 -

 Key: DRILL-3435
 URL: https://issues.apache.org/jira/browse/DRILL-3435
 Project: Apache Drill
  Issue Type: Bug
  Components: Documentation
Affects Versions: 1.0.0
Reporter: Andy Pernsteiner
Assignee: Bridget Bevens
Priority: Minor
  Labels: documentation

 Not only does drill have a number of reserved keywords that require 
 backticking (``), there also appear to be some reserved words that require 
 extra care, using table aliases to be able to perform queries.   One that 
 we've found so far is 'user' .  EG, consider the following scenario:
 bq. /usr/bin/sqlline -u jdbc:drill: -n root
 then:
 {code} select user from 
 `profiles/2aa32e9e-bdae-8949-8461-c14dafe63ee0.sys.drill` ;
 +---+
 | user  |
 +---+
 | root  |
 +---+
 {code}
 But the actual file in question has the 'user' as a different user:
 {code} cat 2aa32e9e-bdae-8949-8461-c14dafe63ee0.sys.drill|egrep -o 
 'user\:\[a-z]+\'
 user:apernsteiner
 {code} 
 The workaround  is to alias the table (t) and prefix the 'user' column in the 
 resultset w/ the table alias :
 {code}
 0: jdbc:drill: select t.`user` from 
 `profiles/2aa32e9e-bdae-8949-8461-c14dafe63ee0.sys.drill` t ;
 +-+
 |  user   |
 +-+
 | apernsteiner  |
 +-+
 {code}
 @jinfeng gave the following explanation on the user@ list:
 {quote}
 'user' is a SQL reserved word.
 When it's used alone, it is a system function, just like CURRENT_USER.  See
 http://calcite.incubator.apache.org/docs/reference.html  (System functions
 section).
 When 'user' is qualified with a table alias, it becomes a column
 identifier. 
 {quote}
 The drill documentation @ https://drill.apache.org/docs/reserved-keywords/ 
 merely says to use backticks (``), not to do any table aliasing.  For those 
 who have columns named 'user', this may be misleading...



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

[jira] [Commented] (DRILL-3435) Some reserved-keywords require table aliasing

2015-07-01 Thread Andy Pernsteiner (JIRA)


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

Andy Pernsteiner commented on DRILL-3435:
-

Maybe I'm missing something here, but this is a relatively specific case, and 
in fact, my queries against other columns in this JSON file do NOT require any 
table aliasing, because this is not a nested JSON doc (at least, not the fields 
I'm going after)  EG:

{code}
: jdbc:drill: select id from profiles limit 3;
+-+
|   id|
+-+
| {part1:3069735710943609483,part2:-1130875713383276112}  |
| {part1:3069511572705759702,part2:-8164107516750810817}  |
| {part1:3057076082656734793,part2:-4260511657052163769}  |
+-+
3 rows selected (2.839 seconds)

{code}

So that works, however running w/ `user`  does not:


{code}

0: jdbc:drill: select `user` from profiles limit 3;
+---+
| user  |
+---+
| apernsteiner  |
| apernsteiner  |
| apernsteiner  |
+---+
3 rows selected (2.141 seconds)

{code}

Also, I'm not sure what you mean by your statement : 

{quote}
..'user' is recognized as a function in this case, and the query fails..
{quote}

What do you mean by the query fails?  It doesn't actually fail, it returns data 
which would be confusing to someone who ran a query against another column in 
this file/table, where they got the actual data, and not the result of a 
special function.



 Some reserved-keywords require table aliasing
 -

 Key: DRILL-3435
 URL: https://issues.apache.org/jira/browse/DRILL-3435
 Project: Apache Drill
  Issue Type: Bug
  Components: Documentation
Affects Versions: 1.0.0
Reporter: Andy Pernsteiner
Assignee: Bridget Bevens
Priority: Minor
  Labels: documentation

 Not only does drill have a number of reserved keywords that require 
 backticking (``), there also appear to be some reserved words that require 
 extra care, using table aliases to be able to perform queries.   One that 
 we've found so far is 'user' .  EG, consider the following scenario:
 bq. /usr/bin/sqlline -u jdbc:drill: -n root
 then:
 {code} select user from 
 `profiles/2aa32e9e-bdae-8949-8461-c14dafe63ee0.sys.drill` ;
 +---+
 | user  |
 +---+
 | root  |
 +---+
 {code}
 But the actual file in question has the 'user' as a different user:
 {code} cat 2aa32e9e-bdae-8949-8461-c14dafe63ee0.sys.drill|egrep -o 
 'user\:\[a-z]+\'
 user:apernsteiner
 {code} 
 The workaround  is to alias the table (t) and prefix the 'user' column in the 
 resultset w/ the table alias :
 {code}
 0: jdbc:drill: select t.`user` from 
 `profiles/2aa32e9e-bdae-8949-8461-c14dafe63ee0.sys.drill` t ;
 +-+
 |  user   |
 +-+
 | apernsteiner  |
 +-+
 {code}
 @jinfeng gave the following explanation on the user@ list:
 {quote}
 'user' is a SQL reserved word.
 When it's used alone, it is a system function, just like CURRENT_USER.  See
 http://calcite.incubator.apache.org/docs/reference.html  (System functions
 section).
 When 'user' is qualified with a table alias, it becomes a column
 identifier. 
 {quote}
 The drill documentation @ https://drill.apache.org/docs/reserved-keywords/ 
 merely says to use backticks (``), not to do any table aliasing.  For those 
 who have columns named 'user', this may be misleading...



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

[jira] [Assigned] (DRILL-3443) Flatten function raise exception when JSON files have different schema

2015-07-01 Thread Jason Altekruse (JIRA)


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

Jason Altekruse reassigned DRILL-3443:
--

Assignee: Jason Altekruse  (was: Daniel Barclay (Drill))

 Flatten function raise exception when JSON files have different schema
 --

 Key: DRILL-3443
 URL: https://issues.apache.org/jira/browse/DRILL-3443
 Project: Apache Drill
  Issue Type: Bug
  Components: Execution - Data Types
Affects Versions: 1.0.0
 Environment: DRILL 1.0 Embedded (running on OSX with Java 8)
 DRILL 1.0 Deployed on MapR 4.1 Sandbox
Reporter: Tugdual Grall
Assignee: Jason Altekruse
Priority: Critical

 I have 2 JSON documents:
 {code}
 {
   name : PPRODUCT_002,
   price : 200.00,
   tags : [sports , cool, ocean]
 }
 {
   name : PPRODUCT_001,
   price : 100.00
 }
 {code}
 And I execute this query:
 {code}
 SELECT name, flatten(tags)
 FROM dfs.`data/json_array/*.json`
 {code}
 If the JSON Documents are located in 2 different files and the first file 
 does not contains the tags (product 001 in 001.json ), the following 
 exception is raised:
 {code}
 org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR: 
 java.lang.ClassCastException: Cannot cast 
 org.apache.drill.exec.vector.NullableIntVector to 
 org.apache.drill.exec.vector.RepeatedValueVector Fragment 0:0 [Error Id: 
 4bb5b9e4-0de1-48e9-a0f3-956339608903 on 192.168.99.13:31010]
 {code}
 It is working if:
 * All the JSON documents are in a single json file (order is not important)
 * if the product with the tags attribute is first on the file system, for 
 example you put product 02 in 000.json  (that will be read before 001.json)
 This is similar to [DRILL-3334] bug



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

[jira] [Updated] (DRILL-2153) flatten function null handling options

2015-07-01 Thread Jason Altekruse (JIRA)


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

Jason Altekruse updated DRILL-2153:
---
Fix Version/s: (was: 1.2.0)
   1.3.0

 flatten function null handling options
 --

 Key: DRILL-2153
 URL: https://issues.apache.org/jira/browse/DRILL-2153
 Project: Apache Drill
  Issue Type: New Feature
  Components: Execution - Relational Operators
Affects Versions: 0.7.0
 Environment: Sandbox 4.0.2
Reporter: Sudhakar Thota
Assignee: Jason Altekruse
 Fix For: 1.3.0


 Function flatten not handling nulls resulting in eliminating relevant records 



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

[jira] [Comment Edited] (DRILL-3435) Some reserved-keywords require table aliasing

2015-07-01 Thread Kristine Hahn (JIRA)


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

Kristine Hahn edited comment on DRILL-3435 at 7/1/15 4:47 PM:
--

Using a table alias to query nested fields is mentioned a number of times in 
the docs. 
* 
https://drill.apache.org/docs/troubleshooting/#access-nested-fields-without-table-name/alias
* https://drill.apache.org/docs/json-data-model/#analyzing-json
* https://drill.apache.org/docs/selecting-multiple-columns-within-nested-data/
* https://drill.apache.org/docs/from-clause/ (The alias parameter description 
that says In other table references, aliases are optional needs to be changed 
to say that aliases might be required, and then maybe link to 
https://drill.apache.org/docs/json-data-model/#analyzing-json.
* 
https://drill.apache.org/docs/lesson-2-run-queries-with-ansi-sql/#queries-in-this-lesson
* 
https://drill.apache.org/docs/lesson-3-run-queries-on-complex-data-types/#explore-clickstream-data:


was (Author: krishahn):
Using a table alias to query nested fields is mentioned a number of times in 
the docs. 
* 
https://drill.apache.org/docs/troubleshooting/#access-nested-fields-without-table-name/alias
* https://drill.apache.org/docs/json-data-model/#analyzing-json
* https://drill.apache.org/docs/selecting-multiple-columns-within-nested-data/
* https://drill.apache.org/docs/from-clause/ (The alias parameter description 
that says In other table references, aliases are optional needs to be changed 
to say that aliases might be required, and then maybe link to 
https://drill.apache.org/docs/json-data-model/#analyzing-json.
* 
https://drill.apache.org/docs/lesson-2-run-queries-with-ansi-sql/#queries-in-this-lesson
* 
https://drill.apache.org/docs/lesson-3-run-queries-on-complex-data-types/#explore-clickstream-data:

The need for the alias might be unrelated to the reserved word.

 Some reserved-keywords require table aliasing
 -

 Key: DRILL-3435
 URL: https://issues.apache.org/jira/browse/DRILL-3435
 Project: Apache Drill
  Issue Type: Bug
  Components: Documentation
Affects Versions: 1.0.0
Reporter: Andy Pernsteiner
Assignee: Bridget Bevens
Priority: Minor
  Labels: documentation

 Not only does drill have a number of reserved keywords that require 
 backticking (``), there also appear to be some reserved words that require 
 extra care, using table aliases to be able to perform queries.   One that 
 we've found so far is 'user' .  EG, consider the following scenario:
 bq. /usr/bin/sqlline -u jdbc:drill: -n root
 then:
 {code} select user from 
 `profiles/2aa32e9e-bdae-8949-8461-c14dafe63ee0.sys.drill` ;
 +---+
 | user  |
 +---+
 | root  |
 +---+
 {code}
 But the actual file in question has the 'user' as a different user:
 {code} cat 2aa32e9e-bdae-8949-8461-c14dafe63ee0.sys.drill|egrep -o 
 'user\:\[a-z]+\'
 user:apernsteiner
 {code} 
 The workaround  is to alias the table (t) and prefix the 'user' column in the 
 resultset w/ the table alias :
 {code}
 0: jdbc:drill: select t.`user` from 
 `profiles/2aa32e9e-bdae-8949-8461-c14dafe63ee0.sys.drill` t ;
 +-+
 |  user   |
 +-+
 | apernsteiner  |
 +-+
 {code}
 @jinfeng gave the following explanation on the user@ list:
 {quote}
 'user' is a SQL reserved word.
 When it's used alone, it is a system function, just like CURRENT_USER.  See
 http://calcite.incubator.apache.org/docs/reference.html  (System functions
 section).
 When 'user' is qualified with a table alias, it becomes a column
 identifier. 
 {quote}
 The drill documentation @ https://drill.apache.org/docs/reserved-keywords/ 
 merely says to use backticks (``), not to do any table aliasing.  For those 
 who have columns named 'user', this may be misleading...



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

[jira] [Commented] (DRILL-2235) Assert when NOT IN clause contains multiple columns

2015-07-01 Thread Aman Sinha (JIRA)


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

Aman Sinha commented on DRILL-2235:
---

This query plans successfully since we now support  (since Drill 1.0) 
NestedLoopJoin with scalar subqueries.   Here's a plan with query agains TPC-H:

{code}
0: jdbc:drill:zk=local explain plan for select n1.n_name from 
cp.`tpch/nation.parquet` n1 where (n1.n_nationkey, n1.n_regionkey) not in 
(select n2.n_nationkey, n2.n_regionkey from cp.`tpch/nation.parquet` n2 where 
n2.n_regionkey  10);
+--+--+
| text | json |
+--+--+
| 00-00Screen
00-01  Project(n_name=[$0])
00-02SelectionVectorRemover
00-03  Filter(condition=[NOT(CASE(=($1, 0), false, IS NOT NULL($7), 
true, IS NULL($3), null, IS NULL($4), null, ($2, $1), null, false))])
00-04HashJoin(condition=[AND(=($3, $5), =($4, $6))], 
joinType=[left])
00-06  Project(n_name=[$2], $f0=[$3], $f1=[$4], f5=[$0], f6=[$1])
00-08NestedLoopJoin(condition=[true], joinType=[inner])
00-11  Project(n_nationkey=[$2], n_regionkey=[$0], n_name=[$1])
00-14Scan(groupscan=[ParquetGroupScan 
[entries=[ReadEntryWithPath [path=classpath:/tpch/nation.parquet]], 
selectionRoot=classpath:/tpch/nation.parquet, numFiles=1, 
columns=[`n_nationkey`, `n_regionkey`, `n_name`]]])
00-10  StreamAgg(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0, 
$1)])
00-13Project($f0=[$0], $f1=[$1], $f2=[true])
00-16  SelectionVectorRemover
00-18Filter(condition=[($1, 10)])
00-20  Project(n_nationkey=[$1], n_regionkey=[$0])
00-21Scan(groupscan=[ParquetGroupScan 
[entries=[ReadEntryWithPath [path=classpath:/tpch/nation.parquet]], 
selectionRoot=classpath:/tpch/nation.parquet, numFiles=1, 
columns=[`n_nationkey`, `n_regionkey`]]])
00-05  Project($f00=[$0], $f10=[$1], $f2=[$2])
00-07HashAgg(group=[{0, 1}], agg#0=[MIN($2)])
00-09  Project($f0=[$0], $f1=[$1], $f2=[true])
00-12SelectionVectorRemover
00-15  Filter(condition=[($1, 10)])
00-17Project(n_nationkey=[$1], n_regionkey=[$0])
00-19  Scan(groupscan=[ParquetGroupScan 
[entries=[ReadEntryWithPath [path=classpath:/tpch/nation.parquet]], 
selectionRoot=classpath:/tpch/nation.parquet, numFiles=1, 
columns=[`n_nationkey`, `n_regionkey`]]])
{code} 

However, note that the StreamAgg is doing a COUNT($0, $1)  .. it seems Calcite 
generates such an aggregate expression.  I am not sure what is the semantics of 
count(a, b).   Running this query fails during execution because we don't 
support this function. 

 Assert when NOT IN clause contains multiple columns
 ---

 Key: DRILL-2235
 URL: https://issues.apache.org/jira/browse/DRILL-2235
 Project: Apache Drill
  Issue Type: Bug
  Components: Query Planning  Optimization
Affects Versions: 0.8.0
Reporter: Victoria Markman
Assignee: Aman Sinha
 Fix For: 1.2.0


 {code}
 0: jdbc:drill:schema=dfs select * from t1;
 ++++
 | a1 | b1 | c1 |
 ++++
 | 1  | a  | 2015-01-01 |
 | 2  | b  | 2015-01-02 |
 | 3  | c  | 2015-01-03 |
 | 4  | null   | 2015-01-04 |
 | 5  | e  | 2015-01-05 |
 | 6  | f  | 2015-01-06 |
 | 7  | g  | 2015-01-07 |
 | null   | h  | 2015-01-08 |
 | 9  | i  | null   |
 | 10 | j  | 2015-01-10 |
 ++++
 10 rows selected (0.056 seconds)
 0: jdbc:drill:schema=dfs select * from t2;
 ++++
 | a2 | b2 | c2 |
 ++++
 | 0  | zzz| 2014-12-31 |
 | 1  | a  | 2015-01-01 |
 | 2  | b  | 2015-01-02 |
 | 2  | b  | 2015-01-02 |
 | 2  | b  | 2015-01-02 |
 | 3  | c  | 2015-01-03 |
 | 4  | d  | 2015-01-04 |
 | 5  | e  | 2015-01-05 |
 | 6  | f  | 2015-01-06 |
 | 7  | g  | 2015-01-07 |
 | 7  | g  | 2015-01-07 |
 | 8  | h  | 2015-01-08 |
 | 9  | i  | 2015-01-09 |
 ++++
 13 rows selected (0.069 seconds)
 {code}
 IN clause returns correct result:
 {code}
 0: jdbc:drill:schema=dfs select count(*) from t1 where (a1, b1) in (select 
 a2, b2 from t2);
 ++
 |

[jira] [Updated] (DRILL-3447) Doc. pages don't let text wrap at certain widths

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

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

Daniel Barclay (Drill) updated DRILL-3447:
--
Description:
Although the documentation pages sometimes are styled to not prohibit browsers
from wrapping text to fit, at some browser window widths, when the outline
appears on the left, the styling reverts to fixed-width formatting--but uses a
width that is wider than the available space, meaning that part of the page is
not visible without horizontal scrolling. See the attachment.

Why does the styling switch to a fixed width in the first place? If we want to
prevent the lines of text from becoming so long that they are hard to read, set
the max-width property, not the width property. Then we don't block the
browser's usual ability to try to fit the content into the user's chosen
browser window width.

was:
Although the documentation pages sometimes are styled to not prohibit browsers
from wrapping text to fit, at some browser window widths, when the outline
appears on the left, the styling reverts to fixed-width formatting--but uses a
width that is wider than the available space, meaning that part of the page is
not visible without horizontal scrolling.

Doc. pages don't let text wrap at certain widths

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

Although the documentation pages sometimes are styled to not prohibit
browsers from wrapping text to fit, at some browser window widths, when the
outline appears on the left, the styling reverts to fixed-width
formatting--but uses a width that is wider than the available space, meaning
that part of the page is not visible without horizontal scrolling. See the
attachment.
Why does the styling switch to a fixed width in the first place? If we want
to prevent the lines of text from becoming so long that they are hard to
read, set the max-width property, not the width property. Then we don't
block the browser's usual ability to try to fit the content into the user's
chosen browser window width.

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

1 2 3 >

1 - 100 of 270 matches

Mail list logo