[jira] [Commented] (DRILL-3121) Hive partition pruning is not happening
[
https://issues.apache.org/jira/browse/DRILL-3121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14591355#comment-14591355
]
blake.liu commented on DRILL-3121:
--
+1. But my test results a little bit different.
If the query like this {code}where month = '01'{code} or {code}where month in
('01', '02'){code} , drill scan the specify partition, but if query {code}where
month > '02'{code} , drill scan all the partitions.
> Hive partition pruning is not happening
> ---
>
> Key: DRILL-3121
> URL: https://issues.apache.org/jira/browse/DRILL-3121
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.0.0
>Reporter: Hao Zhu
>Assignee: Mehant Baid
> Fix For: 1.1.0
>
>
> Tested on 1.0.0 with below commit id, and hive 0.13.
> {code}
> > select * from sys.version;
> +---+++--++
> | commit_id |
> commit_message |commit_time |
> build_email | build_time |
> +---+++--++
> | d8b19759657698581cc0d01d7038797952888123 | DRILL-3100:
> TestImpersonationDisabledWithMiniDFS fails on Windows | 15.05.2015 @
> 01:18:03 EDT | Unknown | 15.05.2015 @ 03:07:10 EDT |
> +---+++--++
> 1 row selected (0.083 seconds)
> {code}
> How to reproduce:
> 1. Use hive to create below partition table:
> {code}
> CREATE TABLE partition_table(id INT, username string)
> PARTITIONED BY(year STRING, month STRING)
> ROW FORMAT DELIMITED FIELDS TERMINATED BY ",";
> insert into table partition_table PARTITION(year='2014',month='11') select
> 1,'u' from passwords limit 1;
> insert into table partition_table PARTITION(year='2014',month='12') select
> 2,'s' from passwords limit 1;
> insert into table partition_table PARTITION(year='2015',month='01') select
> 3,'e' from passwords limit 1;
> insert into table partition_table PARTITION(year='2015',month='02') select
> 4,'r' from passwords limit 1;
> insert into table partition_table PARTITION(year='2015',month='03') select
> 5,'n' from passwords limit 1;
> {code}
> 2. Hive query can do partition pruning for below 2 queries:
> {code}
> hive> explain EXTENDED select * from partition_table where year='2015' and
> month in ( '02','03') ;
> partition values:
> month 02
> year 2015
> partition values:
> month 03
> year 2015
> explain EXTENDED select * from partition_table where year='2015' and (month
> >= '02' and month <= '03') ;
> partition values:
> month 02
> year 2015
> partition values:
> month 03
> year 2015
> {code}
> Hive only scans 2 partitions -- 2015/02 and 2015/03.
> 3. Drill can not do partition pruning for below 2 queries:
> {code}
> > explain plan for select * from hive.partition_table where `year`='2015' and
> > `month` in ('02','03');
> +--+--+
> | text | json |
> +--+--+
> | 00-00Screen
> 00-01 Project(id=[$0], username=[$1], year=[$2], month=[$3])
> 00-02SelectionVectorRemover
> 00-03 Filter(condition=[AND(=($2, '2015'), OR(=($3, '02'), =($3,
> '03')))])
> 00-04Scan(groupscan=[HiveScan [table=Table(dbName:default,
> tableName:partition_table),
> inputSplits=[maprfs:/user/hive/warehouse/partition_table/year=2015/month=01/00_0:0+4,
> maprfs:/user/hive/warehouse/partition_table/year=2015/month=02/00_0:0+4,
> maprfs:/user/hive/warehouse/partition_table/year=2015/month=03/00_0:0+4],
> columns=[`*`], partitions= [Partition(values:[2015, 01]),
> Partition(values:[2015, 02]), Partition(values:[2015, 03])]]])
> > explain plan for select * from hive.partition_table where `year`='2015' and
> > (`month` >= '02' and `month` <= '03' );
> +--+--+
> | text | json |
> +--+--+
> | 00-00Screen
> 00-01 Project(id=[$0], username=[$1], year=[$2], month=[$3])
> 00-02SelectionVectorRemover
> 00-03 Filter(condition=[AND(=($2, '2015'), >=($3, '02'), <=($3,
> '03'))])
> 00-04Scan(groupscan=[HiveScan [table=Table(dbName:default,
> tableName:partition_table),
> inputSplits=[maprfs:/user/hive/warehouse/partition_tabl
[jira] [Updated] (DRILL-3285) Split DrillCursor.next(), clean up DrillCursor for clarity
[ https://issues.apache.org/jira/browse/DRILL-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-3285: -- Attachment: DRILL-3285.Pt5.3.patch.txt DRILL-3285.AllPts.3.patch.txt > Split DrillCursor.next(), clean up DrillCursor for clarity > -- > > Key: DRILL-3285 > URL: https://issues.apache.org/jira/browse/DRILL-3285 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Reporter: Daniel Barclay (Drill) >Assignee: Deneche A. Hakim > Fix For: 1.1.0 > > Attachments: DRILL-3285.AllPts.1.patch.txt, > DRILL-3285.AllPts.2.patch.txt, DRILL-3285.AllPts.3.patch.txt, > DRILL-3285.Pt1.1.patch.txt, DRILL-3285.Pt2.1.patch.txt, > DRILL-3285.Pt3.1.patch.txt, DRILL-3285.Pt4.1.patch.txt, > DRILL-3285.Pt5.1.patch.txt, DRILL-3285.Pt5.2.patch.txt, > DRILL-3285.Pt5.3.patch.txt > > > Clean up the mess in DrillCursor, namely the poorly named (and of course > undocumented) flow-control flags and the flag-laden next() method. > == > DRILL-3285: Part 1--Prep., Hygiene: Mainly, adding comments. > Added/edited comments: > - field doc. comments > - method doc. comments > - branch/block comments > Removed unused recordBatchCount and getRecordBatchCount(). > Added logger call for spurious batch. > Various cleanup: > - Cleaned up logger. > - Added "final" on updateColumns(). > - Wrapped some lines > - Misc. comment whitespace. > == > DRILL-3285: Part 2--Renaming. > Renamed state/control-flow members: > - started -> initialSchemaLoaded > - first -> beforeFirstBatch > - redoFirstNext -> returnTrueForNextCallToNext > - finished -> afterLastRow > Renamed other items: > - changed -> schemaChanged > - currentBatch -> currentBatchHolder > - DrillResultSet's currentBatch -> batchLoader > == > DRILL-3285: Part 3--Invert beforeFirstBatch -> ! afterFirstBatch. > == > DRILL-3285: Part 4--Reorder fields, updateColumns. > == > DRILL-3285: Part 5--Split old hacky next() into separate methods. > Split the original public next() method (which was hacked to handle an extra, > initial call to read the schema batch) into: > - new loadInitialSchema() (for handling the call for the schema) > - modified next() (for handling normal calls from ResultSet.next()) > - new private nextRowInternally() (for common code) > Pulls invariant afterFirstBatch up out of bogus-batch loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3285) Split DrillCursor.next(), clean up DrillCursor for clarity
[ https://issues.apache.org/jira/browse/DRILL-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-3285: -- Attachment: DRILL-3285.AllPts.2.patch.txt > Split DrillCursor.next(), clean up DrillCursor for clarity > -- > > Key: DRILL-3285 > URL: https://issues.apache.org/jira/browse/DRILL-3285 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Reporter: Daniel Barclay (Drill) >Assignee: Deneche A. Hakim > Fix For: 1.1.0 > > Attachments: DRILL-3285.AllPts.1.patch.txt, > DRILL-3285.AllPts.2.patch.txt, DRILL-3285.Pt1.1.patch.txt, > DRILL-3285.Pt2.1.patch.txt, DRILL-3285.Pt3.1.patch.txt, > DRILL-3285.Pt4.1.patch.txt, DRILL-3285.Pt5.1.patch.txt, > DRILL-3285.Pt5.2.patch.txt > > > Clean up the mess in DrillCursor, namely the poorly named (and of course > undocumented) flow-control flags and the flag-laden next() method. > == > DRILL-3285: Part 1--Prep., Hygiene: Mainly, adding comments. > Added/edited comments: > - field doc. comments > - method doc. comments > - branch/block comments > Removed unused recordBatchCount and getRecordBatchCount(). > Added logger call for spurious batch. > Various cleanup: > - Cleaned up logger. > - Added "final" on updateColumns(). > - Wrapped some lines > - Misc. comment whitespace. > == > DRILL-3285: Part 2--Renaming. > Renamed state/control-flow members: > - started -> initialSchemaLoaded > - first -> beforeFirstBatch > - redoFirstNext -> returnTrueForNextCallToNext > - finished -> afterLastRow > Renamed other items: > - changed -> schemaChanged > - currentBatch -> currentBatchHolder > - DrillResultSet's currentBatch -> batchLoader > == > DRILL-3285: Part 3--Invert beforeFirstBatch -> ! afterFirstBatch. > == > DRILL-3285: Part 4--Reorder fields, updateColumns. > == > DRILL-3285: Part 5--Split old hacky next() into separate methods. > Split the original public next() method (which was hacked to handle an extra, > initial call to read the schema batch) into: > - new loadInitialSchema() (for handling the call for the schema) > - modified next() (for handling normal calls from ResultSet.next()) > - new private nextRowInternally() (for common code) > Pulls invariant afterFirstBatch up out of bogus-batch loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3285) Split DrillCursor.next(), clean up DrillCursor for clarity
[ https://issues.apache.org/jira/browse/DRILL-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-3285: -- Attachment: DRILL-3285.Pt5.2.patch.txt > Split DrillCursor.next(), clean up DrillCursor for clarity > -- > > Key: DRILL-3285 > URL: https://issues.apache.org/jira/browse/DRILL-3285 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Reporter: Daniel Barclay (Drill) >Assignee: Deneche A. Hakim > Fix For: 1.1.0 > > Attachments: DRILL-3285.AllPts.1.patch.txt, > DRILL-3285.Pt1.1.patch.txt, DRILL-3285.Pt2.1.patch.txt, > DRILL-3285.Pt3.1.patch.txt, DRILL-3285.Pt4.1.patch.txt, > DRILL-3285.Pt5.1.patch.txt, DRILL-3285.Pt5.2.patch.txt > > > Clean up the mess in DrillCursor, namely the poorly named (and of course > undocumented) flow-control flags and the flag-laden next() method. > == > DRILL-3285: Part 1--Prep., Hygiene: Mainly, adding comments. > Added/edited comments: > - field doc. comments > - method doc. comments > - branch/block comments > Removed unused recordBatchCount and getRecordBatchCount(). > Added logger call for spurious batch. > Various cleanup: > - Cleaned up logger. > - Added "final" on updateColumns(). > - Wrapped some lines > - Misc. comment whitespace. > == > DRILL-3285: Part 2--Renaming. > Renamed state/control-flow members: > - started -> initialSchemaLoaded > - first -> beforeFirstBatch > - redoFirstNext -> returnTrueForNextCallToNext > - finished -> afterLastRow > Renamed other items: > - changed -> schemaChanged > - currentBatch -> currentBatchHolder > - DrillResultSet's currentBatch -> batchLoader > == > DRILL-3285: Part 3--Invert beforeFirstBatch -> ! afterFirstBatch. > == > DRILL-3285: Part 4--Reorder fields, updateColumns. > == > DRILL-3285: Part 5--Split old hacky next() into separate methods. > Split the original public next() method (which was hacked to handle an extra, > initial call to read the schema batch) into: > - new loadInitialSchema() (for handling the call for the schema) > - modified next() (for handling normal calls from ResultSet.next()) > - new private nextRowInternally() (for common code) > Pulls invariant afterFirstBatch up out of bogus-batch loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DRILL-2522) Implement INFORMATION_SCHEMA.* enough for relevant tools [bug]
[
https://issues.apache.org/jira/browse/DRILL-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) closed DRILL-2522.
-
Resolution: Fixed
Closing this multiply-linked report to reduce clutter and because superseded by
DRILL-3309.
> Implement INFORMATION_SCHEMA.* enough for relevant tools [bug]
> --
>
> Key: DRILL-2522
> URL: https://issues.apache.org/jira/browse/DRILL-2522
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Information Schema
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: 1.2.0
>
>
> Note: This JIRA report is/was intended in part for for tracking specific
> noticed differences between Drill and standard SQL (not necessarily
> differences we've already decided to fix), and also in part as a reminder of
> this likelihood of running into problems with tools that we care about (even
> that set of problems isn't known now).
> Drill's {{INFORMATION_SCHEMA}} is not fully compliant with SQL:2011.
> See DRILL-2763 regarding
> {{INFORMATION_SCHEMA.COLUMNS}} (as opposed to other
> {{INFORMATION_SCHEMA.}}_*_ tables/views ).
> Notes (to be edited/triaged/etc):
> - {{INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME}} does not exist.
> - Short-name views of existing tables (e.g., {{TABLES_S}} for {{TABLES}}) do
> not exist.
> - (Most standard-specified tables/views do not exist, but many probably
> aren't relevant for Drill.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3309) Revisit INFORMATION_SCHEMA's SQL compliance.
[
https://issues.apache.org/jira/browse/DRILL-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-3309:
--
Component/s: Storage - Information Schema
> Revisit INFORMATION_SCHEMA's SQL compliance.
>
>
> Key: DRILL-3309
> URL: https://issues.apache.org/jira/browse/DRILL-3309
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Information Schema
>Reporter: Daniel Barclay (Drill)
>
> At some point, review the compliance with the SQL specification of Drill's
> {{INFORMATION_SCHEMA}} schema (other than {{INFORMATION_SCHEMA.COLUMNS}},
> which addressed in DRILL-3308).
> (For reference, see ISO 9075 (SQL spec.) Part 11: Information and Definition
> Schemas (SQL/Schemata).)
> Notes:
> - {{INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME}} does not exist.
> - Short-name views of existing tables (e.g., {{TABLES_S}} for {{TABLES}}) do
> not exist.
> - Most standard-specified tables/views do not exist (but many probably aren't
> relevant for Drill).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2522) Implement INFORMATION_SCHEMA.* enough for relevant tools [bug]
[
https://issues.apache.org/jira/browse/DRILL-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2522:
--
Description:
Note: This JIRA report is/was intended in part for for tracking specific
noticed differences between Drill and standard SQL (not necessarily differences
we've already decided to fix), and also in part as a reminder of this
likelihood of running into problems with tools that we care about (even that
set of problems isn't known now).
Drill's {{INFORMATION_SCHEMA}} is not fully compliant with SQL:2011.
See DRILL-2763 regarding
{{INFORMATION_SCHEMA.COLUMNS}} (as opposed to other {{INFORMATION_SCHEMA.}}_*_
tables/views ).
Notes (to be edited/triaged/etc):
- {{INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME}} does not exist.
- Short-name views of existing tables (e.g., {{TABLES_S}} for {{TABLES}}) do
not exist.
- (Most standard-specified tables/views do not exist, but many probably aren't
relevant for Drill.)
was:
Note: This JIRA report is/was intended in part for for tracking specific
noticed differences between Drill and standard SQL (not necessarily differences
we've already decided to fix), and also in part as a reminder of this
likelihood of running into problems with tools that we care about (even that
set of problems isn't known now).
Drill's {{INFORMATION_SCHEMA.COLUMNS}} is not fully compliant with SQL:2011.
See DRILL-2763 regarding
{{INFORMATION_SCHEMA.COLUMNS}} (as opposed to other {{INFORMATION_SCHEMA.}}_*_
tables/views ).
Notes (to be edited/triaged/etc):
- {{INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME}} does not exist.
- Short-name views of existing tables (e.g., {{TABLES_S}} for {{TABLES}}) do
not exist.
- (Most standard-specified tables/views do not exist, but many probably aren't
relevant for Drill.)
> Implement INFORMATION_SCHEMA.* enough for relevant tools [bug]
> --
>
> Key: DRILL-2522
> URL: https://issues.apache.org/jira/browse/DRILL-2522
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Information Schema
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: 1.2.0
>
>
> Note: This JIRA report is/was intended in part for for tracking specific
> noticed differences between Drill and standard SQL (not necessarily
> differences we've already decided to fix), and also in part as a reminder of
> this likelihood of running into problems with tools that we care about (even
> that set of problems isn't known now).
> Drill's {{INFORMATION_SCHEMA}} is not fully compliant with SQL:2011.
> See DRILL-2763 regarding
> {{INFORMATION_SCHEMA.COLUMNS}} (as opposed to other
> {{INFORMATION_SCHEMA.}}_*_ tables/views ).
> Notes (to be edited/triaged/etc):
> - {{INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME}} does not exist.
> - Short-name views of existing tables (e.g., {{TABLES_S}} for {{TABLES}}) do
> not exist.
> - (Most standard-specified tables/views do not exist, but many probably
> aren't relevant for Drill.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3308) Revisit INFORMATION_SCHEMA.COLUMNS's SQL compliance.
[
https://issues.apache.org/jira/browse/DRILL-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-3308:
--
Component/s: Storage - Information Schema
> Revisit INFORMATION_SCHEMA.COLUMNS's SQL compliance.
>
>
> Key: DRILL-3308
> URL: https://issues.apache.org/jira/browse/DRILL-3308
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Information Schema
>Reporter: Daniel Barclay (Drill)
>
> At some point, review the compliance with the SQL specification of Drill's
> INFORMATION_SCHEMA.COLUMNS table.
> {{TABLE_NAME}} holds the original form of the identifier but _might_ need to
> be uppercased here to be compliant (or possibly internal matching queries
> (e.g., for JDBC's getColumns(...)) could be case-insensitive).
> {{COLUMN_NAME}} holds the original form of the identifier but _might_ need to
> be uppercased here to be compliant (or possibly internal matching queries
> (e.g., for JDBC's getColumns(...)) could be case-insensitive).
> {{MAXIMUM_CARDINALITY}} does not exist.
> The following columns do not exist:
> - {{CHARACTER_SET_CATALOG}}
> - {{CHARACTER_SET_SCHEMA}}
> - {{CHARACTER_SET_NAME}}
> - {{COLLATION_CATALOG}}
> - {{COLLATION_SCHEMA}}
> - {{COLLATION_NAME}}
> - {{DOMAIN_CATALOG}}
> - {{DOMAIN_SCHEMA}}
> - {{DOMAIN_NAME}}
> - {{UDT_CATALOG}}
> - {{UDT_SCHEMA}}
> - {{UDT_NAME}}
> - {{SCOPE_CATALOG}}
> - {{SCOPE_SCHEMA}}
> - {{SCOPE_NAME}}
> - {{DTD_IDENTIFIER}}
> - {{IS_SELF_REFERENCING}}
> - {{IS_IDENTITY}}
> - {{IDENTITY_GENERATION}}
> - {{IDENTITY_START}}
> - {{IDENTITY_INCREMENT}}
> - {{IDENTITY_MAXIMUM}}
> - {{IDENTITY_MINIMUM}}
> - {{IDENTITY_CYCLE}}
> - {{IS_GENERATED}}
> - {{GENERATION_EXPRESSION}}
> - {{IS_SYSTEM_TIME_PERIOD_START}}
> - {{IS_SYSTEM_TIME_PERIOD_END}}
> - {{SYSTEM_TIME_PERIOD_TIMESTAMP_GENERATION}}
> - {{IS_UPDATABLE}}
> - {{DECLARED_DATA_TYPE}}
> - {{DECLARED_NUMERIC_PRECISION}}
> - {{DECLARED_NUMERIC_SCALE}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3308) Revisit INFORMATION_SCHEMA.COLUMNS's SQL compliance.
[
https://issues.apache.org/jira/browse/DRILL-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-3308:
--
Component/s: (was: Metadata)
> Revisit INFORMATION_SCHEMA.COLUMNS's SQL compliance.
>
>
> Key: DRILL-3308
> URL: https://issues.apache.org/jira/browse/DRILL-3308
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Daniel Barclay (Drill)
>Assignee: Steven Phillips
>
> At some point, review the compliance with the SQL specification of Drill's
> INFORMATION_SCHEMA.COLUMNS table.
> {{TABLE_NAME}} holds the original form of the identifier but _might_ need to
> be uppercased here to be compliant (or possibly internal matching queries
> (e.g., for JDBC's getColumns(...)) could be case-insensitive).
> {{COLUMN_NAME}} holds the original form of the identifier but _might_ need to
> be uppercased here to be compliant (or possibly internal matching queries
> (e.g., for JDBC's getColumns(...)) could be case-insensitive).
> {{MAXIMUM_CARDINALITY}} does not exist.
> The following columns do not exist:
> - {{CHARACTER_SET_CATALOG}}
> - {{CHARACTER_SET_SCHEMA}}
> - {{CHARACTER_SET_NAME}}
> - {{COLLATION_CATALOG}}
> - {{COLLATION_SCHEMA}}
> - {{COLLATION_NAME}}
> - {{DOMAIN_CATALOG}}
> - {{DOMAIN_SCHEMA}}
> - {{DOMAIN_NAME}}
> - {{UDT_CATALOG}}
> - {{UDT_SCHEMA}}
> - {{UDT_NAME}}
> - {{SCOPE_CATALOG}}
> - {{SCOPE_SCHEMA}}
> - {{SCOPE_NAME}}
> - {{DTD_IDENTIFIER}}
> - {{IS_SELF_REFERENCING}}
> - {{IS_IDENTITY}}
> - {{IDENTITY_GENERATION}}
> - {{IDENTITY_START}}
> - {{IDENTITY_INCREMENT}}
> - {{IDENTITY_MAXIMUM}}
> - {{IDENTITY_MINIMUM}}
> - {{IDENTITY_CYCLE}}
> - {{IS_GENERATED}}
> - {{GENERATION_EXPRESSION}}
> - {{IS_SYSTEM_TIME_PERIOD_START}}
> - {{IS_SYSTEM_TIME_PERIOD_END}}
> - {{SYSTEM_TIME_PERIOD_TIMESTAMP_GENERATION}}
> - {{IS_UPDATABLE}}
> - {{DECLARED_DATA_TYPE}}
> - {{DECLARED_NUMERIC_PRECISION}}
> - {{DECLARED_NUMERIC_SCALE}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3308) Revisit INFORMATION_SCHEMA.COLUMNS's SQL compliance.
[
https://issues.apache.org/jira/browse/DRILL-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-3308:
--
Assignee: (was: Steven Phillips)
> Revisit INFORMATION_SCHEMA.COLUMNS's SQL compliance.
>
>
> Key: DRILL-3308
> URL: https://issues.apache.org/jira/browse/DRILL-3308
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Daniel Barclay (Drill)
>
> At some point, review the compliance with the SQL specification of Drill's
> INFORMATION_SCHEMA.COLUMNS table.
> {{TABLE_NAME}} holds the original form of the identifier but _might_ need to
> be uppercased here to be compliant (or possibly internal matching queries
> (e.g., for JDBC's getColumns(...)) could be case-insensitive).
> {{COLUMN_NAME}} holds the original form of the identifier but _might_ need to
> be uppercased here to be compliant (or possibly internal matching queries
> (e.g., for JDBC's getColumns(...)) could be case-insensitive).
> {{MAXIMUM_CARDINALITY}} does not exist.
> The following columns do not exist:
> - {{CHARACTER_SET_CATALOG}}
> - {{CHARACTER_SET_SCHEMA}}
> - {{CHARACTER_SET_NAME}}
> - {{COLLATION_CATALOG}}
> - {{COLLATION_SCHEMA}}
> - {{COLLATION_NAME}}
> - {{DOMAIN_CATALOG}}
> - {{DOMAIN_SCHEMA}}
> - {{DOMAIN_NAME}}
> - {{UDT_CATALOG}}
> - {{UDT_SCHEMA}}
> - {{UDT_NAME}}
> - {{SCOPE_CATALOG}}
> - {{SCOPE_SCHEMA}}
> - {{SCOPE_NAME}}
> - {{DTD_IDENTIFIER}}
> - {{IS_SELF_REFERENCING}}
> - {{IS_IDENTITY}}
> - {{IDENTITY_GENERATION}}
> - {{IDENTITY_START}}
> - {{IDENTITY_INCREMENT}}
> - {{IDENTITY_MAXIMUM}}
> - {{IDENTITY_MINIMUM}}
> - {{IDENTITY_CYCLE}}
> - {{IS_GENERATED}}
> - {{GENERATION_EXPRESSION}}
> - {{IS_SYSTEM_TIME_PERIOD_START}}
> - {{IS_SYSTEM_TIME_PERIOD_END}}
> - {{SYSTEM_TIME_PERIOD_TIMESTAMP_GENERATION}}
> - {{IS_UPDATABLE}}
> - {{DECLARED_DATA_TYPE}}
> - {{DECLARED_NUMERIC_PRECISION}}
> - {{DECLARED_NUMERIC_SCALE}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-1687) Remove references to deprecated dense Decimal representation
[ https://issues.apache.org/jira/browse/DRILL-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-1687: - Fix Version/s: (was: 1.1.0) 1.2.0 > Remove references to deprecated dense Decimal representation > > > Key: DRILL-1687 > URL: https://issues.apache.org/jira/browse/DRILL-1687 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Data Types >Reporter: Jason Altekruse >Assignee: Mehant Baid >Priority: Minor > Fix For: 1.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-1626) sqlline echoes statements with unnecessary wrapping
[ https://issues.apache.org/jira/browse/DRILL-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-1626: - Fix Version/s: (was: 1.1.0) 1.2.0 > sqlline echoes statements with unnecessary wrapping > --- > > Key: DRILL-1626 > URL: https://issues.apache.org/jira/browse/DRILL-1626 > Project: Apache Drill > Issue Type: Bug > Components: Client - CLI > Environment: sqlline running under Eclipse on OSX >Reporter: Chris Westin >Assignee: Mehant Baid >Priority: Minor > Fix For: 1.2.0 > > > I type a command in sqlline, and when it is echoed, it is unnecessarily > wrapped (making it hard to read, as well as casting uncertainty on what I was > doing). Example: > 0: jdbc:drill:zk=local> create table donuts_parquet as select * from > `donuts.json`; > create table donuts_parquet as select * from `donuts.jso > n`; > ++---+ > | Fragment | Number of records written | > ++---+ > | 0_0| 5 | > That's sqlline adding a newline after jso and before n in the echoed command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3309) Revisit INFORMATION_SCHEMA's SQL compliance.
[
https://issues.apache.org/jira/browse/DRILL-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-3309:
--
Description:
At some point, review the compliance with the SQL specification of Drill's
{{INFORMATION_SCHEMA}} schema (other than {{INFORMATION_SCHEMA.COLUMNS}}, which
addressed in DRILL-3308).
(For reference, see ISO 9075 (SQL spec.) Part 11: Information and Definition
Schemas (SQL/Schemata).)
Notes:
- {{INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME}} does not exist.
- Short-name views of existing tables (e.g., {{TABLES_S}} for {{TABLES}}) do
not exist.
- Most standard-specified tables/views do not exist (but many probably aren't
relevant for Drill).
was:
At some point, review the compliance with the SQL specification of Drill's
{{INFORMATION_SCHEMA}} schema (other than {{INFORMATION_SCHEMA.COLUMNS}}, which
addressed in DRILL-3308).
(For reference, see ISO 9075 (SQL spec.) Part 11: Information and Definition
Schemas (SQL/Schemata).)
Notes:
- INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME does not exist.
- Short-name views of existing tables (e.g., TABLES_S for TABLES) do not exist.
- Most standard-specified tables/views do not exist (but many probably aren't
relevant for Drill).
> Revisit INFORMATION_SCHEMA's SQL compliance.
>
>
> Key: DRILL-3309
> URL: https://issues.apache.org/jira/browse/DRILL-3309
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Daniel Barclay (Drill)
>
> At some point, review the compliance with the SQL specification of Drill's
> {{INFORMATION_SCHEMA}} schema (other than {{INFORMATION_SCHEMA.COLUMNS}},
> which addressed in DRILL-3308).
> (For reference, see ISO 9075 (SQL spec.) Part 11: Information and Definition
> Schemas (SQL/Schemata).)
> Notes:
> - {{INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME}} does not exist.
> - Short-name views of existing tables (e.g., {{TABLES_S}} for {{TABLES}}) do
> not exist.
> - Most standard-specified tables/views do not exist (but many probably aren't
> relevant for Drill).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2557) COALESCE function returns ArrayIndexOutOfBoundsException when no arguments are passed in
[
https://issues.apache.org/jira/browse/DRILL-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Parth Chandra updated DRILL-2557:
-
Fix Version/s: (was: 1.1.0)
1.2.0
> COALESCE function returns ArrayIndexOutOfBoundsException when no arguments
> are passed in
>
>
> Key: DRILL-2557
> URL: https://issues.apache.org/jira/browse/DRILL-2557
> Project: Apache Drill
> Issue Type: Bug
> Components: Functions - Drill
>Affects Versions: 0.8.0
>Reporter: Victoria Markman
>Assignee: Mehant Baid
>Priority: Minor
> Fix For: 1.2.0
>
>
> {code}
> 0: jdbc:drill:schema=dfs> select coalesce() from j2;
> Query failed: ArrayIndexOutOfBoundsException: -1
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3309) Revisit INFORMATION_SCHEMA's SQL compliance.
[
https://issues.apache.org/jira/browse/DRILL-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-3309:
--
Description:
At some point, review the compliance with the SQL specification of Drill's
{{INFORMATION_SCHEMA}} schema (other than {{INFORMATION_SCHEMA.COLUMNS}}, which
addressed in DRILL-3308).
(For reference, see ISO 9075 (SQL spec.) Part 11: Information and Definition
Schemas (SQL/Schemata).)
Notes:
- INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME does not exist.
- Short-name views of existing tables (e.g., TABLES_S for TABLES) do not exist.
- Most standard-specified tables/views do not exist (but many probably aren't
relevant for Drill).
was:
At some point, review the compliance with the SQL specification of Drill's
{{INFORMATION_SCHEMA}} schema (other than {{INFORMATION_SCHEMA.COLUMNS}}, which
addressed in DRILL-3308).
INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME does not exist.
Short-name views of existing tables (e.g., TABLES_S for TABLES) do not exist.
Most standard-specified tables/views do not exist, but many probably aren't
relevant for Drill.
> Revisit INFORMATION_SCHEMA's SQL compliance.
>
>
> Key: DRILL-3309
> URL: https://issues.apache.org/jira/browse/DRILL-3309
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Daniel Barclay (Drill)
>
> At some point, review the compliance with the SQL specification of Drill's
> {{INFORMATION_SCHEMA}} schema (other than {{INFORMATION_SCHEMA.COLUMNS}},
> which addressed in DRILL-3308).
> (For reference, see ISO 9075 (SQL spec.) Part 11: Information and Definition
> Schemas (SQL/Schemata).)
> Notes:
> - INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME does not exist.
> - Short-name views of existing tables (e.g., TABLES_S for TABLES) do not
> exist.
> - Most standard-specified tables/views do not exist (but many probably aren't
> relevant for Drill).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2200) Obscure error message from kvgen when the field does not exist in a parquet file
[
https://issues.apache.org/jira/browse/DRILL-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Parth Chandra updated DRILL-2200:
-
Fix Version/s: (was: 1.1.0)
1.2.0
> Obscure error message from kvgen when the field does not exist in a parquet
> file
>
>
> Key: DRILL-2200
> URL: https://issues.apache.org/jira/browse/DRILL-2200
> Project: Apache Drill
> Issue Type: Bug
> Components: Functions - Drill
>Reporter: Rahul Challapalli
>Assignee: Mehant Baid
>Priority: Minor
> Fix For: 1.2.0
>
> Attachments: data.parquet
>
>
> git.commit.id.abbrev=3d863b5
> Json Data Set :
> {code}
> {
> "id":1,
> "map": {
> "map1":{"col1":1, "col2":2}
> }
> }
> {code}
> Equivalent Parquet File is attached.
> The below response properly indicates the reason for failure
> {code}
> select kvgen(t.map.abcd) from dfs.flatten_operators.`data.json` t;
> Query failed: RemoteRpcException: Failure while running fragment., kvgen
> function only supports Simple maps as input [
> 9b441359-9f04-4199-8cca-cdc23aaab517 on qa-node191.qa.lab:31010 ]
> [ 9b441359-9f04-4199-8cca-cdc23aaab517 on qa-node191.qa.lab:31010 ]
> {code}
> However the same query on an equivalent parquet file returns an obscure error
> message
> {code}
> select kvgen(t.map.abcd) from `data.parquet` t;
> Query failed: RemoteRpcException: Failure while running fragment., Unable to
> find holder type for minorType: LATE [ 9697f4aa-1e8d-4221-8e7f-4d374ffbd916
> on qa-node191.qa.lab:31010 ]
> [ 9697f4aa-1e8d-4221-8e7f-4d374ffbd916 on qa-node191.qa.lab:31010 ]
> {code}
> However if we apply kvgen on a first level non-existent field we get back a
> proper error message even for a parquet file
> {code}
> select kvgen(t.map1) from `data.parquet` t;
> Query failed: RemoteRpcException: Failure while running fragment., kvgen
> function only supports Simple maps as input [
> 1d1c4ca3-ceda-4320-8ff8-fe08afe32090 on qa-node191.qa.lab:31010 ]
> [ 1d1c4ca3-ceda-4320-8ff8-fe08afe32090 on qa-node191.qa.lab:31010 ]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-3309) Revisit INFORMATION_SCHEMA's SQL compliance.
Daniel Barclay (Drill) created DRILL-3309:
-
Summary: Revisit INFORMATION_SCHEMA's SQL compliance.
Key: DRILL-3309
URL: https://issues.apache.org/jira/browse/DRILL-3309
Project: Apache Drill
Issue Type: Bug
Reporter: Daniel Barclay (Drill)
At some point, review the compliance with the SQL specification of Drill's
{{INFORMATION_SCHEMA}} schema (other than {{INFORMATION_SCHEMA.COLUMNS}}, which
addressed in DRILL-3308).
INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME does not exist.
Short-name views of existing tables (e.g., TABLES_S for TABLES) do not exist.
Most standard-specified tables/views do not exist, but many probably aren't
relevant for Drill.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2676) Review Drill casting combinations re SQL standard (ISO 9705:2011 part 2 § 6.13)
[ https://issues.apache.org/jira/browse/DRILL-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-2676: - Fix Version/s: (was: 1.1.0) Future > Review Drill casting combinations re SQL standard (ISO 9705:2011 part 2 § > 6.13) > --- > > Key: DRILL-2676 > URL: https://issues.apache.org/jira/browse/DRILL-2676 > Project: Apache Drill > Issue Type: Task > Components: Execution - Data Types >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > Fix For: Future > > > Drill doesn't allow casting an expression of an ARRAY type to that same ARRAY > type. > That doesn't seem to be compatible with the cast-combinations table in the > SQL spec. (although I haven't checked the rest of the rules yet). > It also seems illogical, since one can't cast something to the type that it > already has. > We should probably review Drill casting combinations against the casting > rules in the SQL specification (ISO 9705:2011 part 2 § 6.13). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2604) Make sure implicit casting rules are the same across drill
[ https://issues.apache.org/jira/browse/DRILL-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-2604: - Fix Version/s: (was: 1.1.0) Future > Make sure implicit casting rules are the same across drill > -- > > Key: DRILL-2604 > URL: https://issues.apache.org/jira/browse/DRILL-2604 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Data Types >Affects Versions: 0.8.0 >Reporter: Victoria Markman >Assignee: Daniel Barclay (Drill) > Fix For: Future > > > This is an enhancement request to standardize rules of implicit cast. > It would be nice if rules in joins, set operations and functions where the > same. > Number of inconcistencies have been found and reported under: > DRILL-2549 - Implicit Cast between integer and varchar columns in a join > should work > DRILL-2433 - Implicit cast between date and timestamp is missing in joins > We agreed that this is not 1.0 item and above mentioned bugs will not be > resolved by GA. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2558) Four different errors are returned when running one COALESCE with multiple arguments of incompatible data types
[
https://issues.apache.org/jira/browse/DRILL-2558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Parth Chandra updated DRILL-2558:
-
Assignee: Mehant Baid (was: Daniel Barclay (Drill))
> Four different errors are returned when running one COALESCE with multiple
> arguments of incompatible data types
> ---
>
> Key: DRILL-2558
> URL: https://issues.apache.org/jira/browse/DRILL-2558
> Project: Apache Drill
> Issue Type: Bug
> Components: Functions - Drill
>Affects Versions: 0.8.0
>Reporter: Victoria Markman
>Assignee: Mehant Baid
> Fix For: 1.1.0
>
>
> Drill tries to do implicit cast during runtime, and we agreed that if
> particular cast is not implemented run time exception is fine for now.
> However, it feels weird to get four of them at the same time.
> I think we should throw exception on the first incompatibility and stop
> processing rest of the arguments.
> {code}
> 0: jdbc:drill:schema=dfs> select coalesce(c_varchar, c_integer, c_bigint,
> c_float, c_double, c_date, c_time, c_timestamp, c_boolean) from j2;
> Query failed: Query stopped., Failure while trying to materialize incoming
> schema. Errors:
>
> Error in expression at index -1. Error: Missing function implementation:
> [castBIT(TIMESTAMP-OPTIONAL)]. Full expression: --UNKNOWN EXPRESSION--.
> Error in expression at index -1. Error: Missing function implementation:
> [castBIT(TIME-OPTIONAL)]. Full expression: --UNKNOWN EXPRESSION--.
> Error in expression at index -1. Error: Missing function implementation:
> [castBIT(DATE-OPTIONAL)]. Full expression: --UNKNOWN EXPRESSION--.
> Error in expression at index -1. Error: Missing function implementation:
> [castFLOAT8(BIT-OPTIONAL)]. Full expression: --UNKNOWN EXPRESSION--.. [
> e2effaf7-6fcc-4d7d-b408-2031aab2a344 on atsqa4-133.qa.lab:31010 ]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2234) IOOB when streaming aggregate is on the left side of hash join
[ https://issues.apache.org/jira/browse/DRILL-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-2234: - Fix Version/s: (was: 1.1.0) 1.2.0 > IOOB when streaming aggregate is on the left side of hash join > -- > > Key: DRILL-2234 > URL: https://issues.apache.org/jira/browse/DRILL-2234 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Relational Operators >Reporter: Mehant Baid >Assignee: Mehant Baid > Fix For: 1.2.0 > > > This issue is similar to DRILL-2107. > Issue can be reproduced by enabling SwapJoinRule in DrillRuleSets and running > the following query. > alter session set `planner.slice_target` = 1; > alter session set `planner.enable_hashagg` = false; > alter session set `planner.enable_streamagg` = true; > select l_suppkey, sum(l_extendedprice)/sum(l_quantity) as avg_price > from cp.`tpch/lineitem.parquet` where l_orderkey in > (select o_orderkey from cp.`tpch/orders.parquet` where o_custkey = 2) > group by l_suppkey having sum(l_extendedprice)/sum(l_quantity) > 1850.0; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DRILL-2480) [umbrella] Identify, fix INFORMATION_SCHEMA and JDBC metadata bugs
[
https://issues.apache.org/jira/browse/DRILL-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) closed DRILL-2480.
-
Resolution: Fixed
Closing this umbrella report to reduce clutter.
> [umbrella] Identify, fix INFORMATION_SCHEMA and JDBC metadata bugs
> --
>
> Key: DRILL-2480
> URL: https://issues.apache.org/jira/browse/DRILL-2480
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC, Metadata
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: 1.1.0
>
>
> This DRILL-2480 is a second-level umbrella/tracking bug to group metadata
> bugs, including other umbrella/tracking bugs, whether in INFORMATION_SCHEMA
> or in the JDBC code that uses INFORMATION_SCHEMA.
> DRILL-2480 partly covers DRILL-2436 ("JDBC enough for relevant tools",
> including metadata).
> DRILL-2480 covers DRILL-2522 ("INFORMATION_SCHEMA enough for relevant tools").
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2419) UDF that returns string representation of expression type
[ https://issues.apache.org/jira/browse/DRILL-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14591266#comment-14591266 ] Daniel Barclay (Drill) commented on DRILL-2419: --- Some possible precedents: "TYPEOF" in SQLite. "EXPRTYPE"in Sybase and SQL Anywhere. "SQL_VARIANT_PROPERTY", which has a second argument taking values such as "BaseType", "Precision", "Scale", etc., in SQL Server. "PG_TYPEOF in PostgreSQL > UDF that returns string representation of expression type > - > > Key: DRILL-2419 > URL: https://issues.apache.org/jira/browse/DRILL-2419 > Project: Apache Drill > Issue Type: Improvement > Components: Functions - Drill >Reporter: Victoria Markman >Assignee: Mehant Baid > Fix For: 1.2.0 > > > Suggested name: typeof (credit goes to Aman) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2845) C++ client: QuerySubmitter does not handle columns with data more than 10K chars
[ https://issues.apache.org/jira/browse/DRILL-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-2845: - Fix Version/s: (was: 1.1.0) Future > C++ client: QuerySubmitter does not handle columns with data more than 10K > chars > > > Key: DRILL-2845 > URL: https://issues.apache.org/jira/browse/DRILL-2845 > Project: Apache Drill > Issue Type: Bug >Reporter: Parth Chandra >Assignee: Parth Chandra >Priority: Minor > Fix For: Future > > > In the synchronous API, the query submitter example program has a hardcoded > buffer size for printing results. This could lead to the test program > crashing if the result data has a field with more than 10K characters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2064) Internal "Float4" and "Float8" names are confusing; rename using "Float" and "Double"
[ https://issues.apache.org/jira/browse/DRILL-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-2064: - Fix Version/s: (was: 1.1.0) Future > Internal "Float4" and "Float8" names are confusing; rename using "Float" and > "Double" > - > > Key: DRILL-2064 > URL: https://issues.apache.org/jira/browse/DRILL-2064 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Data Types >Reporter: Daniel Barclay (Drill) >Assignee: Parth Chandra >Priority: Minor > Fix For: Future > > > [For/from Jacques:] > The internal names (e.g., enumerations, vector subtypes, function names) > containing "Float4" and "Float8" are confusing since they don't correspond to > type names "float" and "double" in Java, etc. > Things currently named using "Float4" should be renamed to names using > "Float"; things currently named using "Float8" should be renamed using > "Double". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2435) Query SCHEMATA using querySubmitter against C++ client return no data
[ https://issues.apache.org/jira/browse/DRILL-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-2435: - Fix Version/s: (was: 1.1.0) 1.2.0 > Query SCHEMATA using querySubmitter against C++ client return no data > - > > Key: DRILL-2435 > URL: https://issues.apache.org/jira/browse/DRILL-2435 > Project: Apache Drill > Issue Type: Bug > Components: Client - C++ >Affects Versions: 0.8.0 >Reporter: Krystal >Assignee: Parth Chandra >Priority: Minor > Fix For: 1.2.0 > > > The following query from querySubmitter against C++ client returns rows with > empty column values: > CATALOG_NAMESCHEMA_NAME SCHEMA_OWNERTYPEIS_MUTABLE > ROW: 1 > ROW: 2 > ROW: 3 > ROW: 4 > ROW: 5 > ROW: 6 > Running the same query from drill, all data is returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3054) C++ Client - Improve heartbeat mechanism to retry a few times before shutting down
[ https://issues.apache.org/jira/browse/DRILL-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-3054: - Fix Version/s: (was: 1.2.0) Future > C++ Client - Improve heartbeat mechanism to retry a few times before > shutting down > --- > > Key: DRILL-3054 > URL: https://issues.apache.org/jira/browse/DRILL-3054 > Project: Apache Drill > Issue Type: Improvement > Components: Client - C++ >Reporter: Parth Chandra >Assignee: Parth Chandra > Fix For: Future > > > The JIRA is to track the concerns raised in the review : > https://reviews.apache.org/r/34072/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-1446) C++ Client. Make Drill Client Logger thread safe
[ https://issues.apache.org/jira/browse/DRILL-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-1446: - Fix Version/s: (was: 1.1.0) Future > C++ Client. Make Drill Client Logger thread safe > > > Key: DRILL-1446 > URL: https://issues.apache.org/jira/browse/DRILL-1446 > Project: Apache Drill > Issue Type: Bug > Components: Client - C++ >Reporter: Xiao Meng >Assignee: Parth Chandra >Priority: Minor > Fix For: Future > > > The C++ client uses ostream/ofstream to log which is not thread-safe. If > multiple thread writing on the logger file, it causes undefined behaviors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3054) C++ Client - Improve heartbeat mechanism to retry a few times before shutting down
[ https://issues.apache.org/jira/browse/DRILL-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-3054: - Fix Version/s: (was: 1.1.0) 1.2.0 > C++ Client - Improve heartbeat mechanism to retry a few times before > shutting down > --- > > Key: DRILL-3054 > URL: https://issues.apache.org/jira/browse/DRILL-3054 > Project: Apache Drill > Issue Type: Improvement > Components: Client - C++ >Reporter: Parth Chandra >Assignee: Parth Chandra > Fix For: 1.2.0 > > > The JIRA is to track the concerns raised in the review : > https://reviews.apache.org/r/34072/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2496) Add SSL support to C++ client
[ https://issues.apache.org/jira/browse/DRILL-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-2496: - Fix Version/s: (was: 1.1.0) 1.2.0 > Add SSL support to C++ client > - > > Key: DRILL-2496 > URL: https://issues.apache.org/jira/browse/DRILL-2496 > Project: Apache Drill > Issue Type: Improvement > Components: Client - C++ >Reporter: Parth Chandra >Assignee: Parth Chandra > Fix For: 1.2.0 > > > Needed for impersonation where username and password are sent over the wire > to the user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3120) Windows startup throws NPE
[ https://issues.apache.org/jira/browse/DRILL-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590974#comment-14590974 ] Parth Chandra commented on DRILL-3120: -- [~adityakishore] Could you take a look? > Windows startup throws NPE > -- > > Key: DRILL-3120 > URL: https://issues.apache.org/jira/browse/DRILL-3120 > Project: Apache Drill > Issue Type: Bug > Components: Client - CLI >Affects Versions: 1.0.0 > Environment: Windows 8.1 VM, JDK 1.7.0_79 >Reporter: Kristine Hahn >Assignee: Aditya Kishore > Fix For: 1.1.0 > > > Install drill snapshot dated 5/15. > Double click sqlline.bat. > Output is: > DRILL_ARGS - "" > HADOOP_HOME not detected... > HBASE_HOME not detected... > Calculating Drill classpath... > Error setting configuration: isolation: java.lang.NullPointerException > apache drill 1.0.0 > "a drill is a terrible thing to waste" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3120) Windows startup throws NPE
[ https://issues.apache.org/jira/browse/DRILL-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-3120: - Assignee: Aditya Kishore > Windows startup throws NPE > -- > > Key: DRILL-3120 > URL: https://issues.apache.org/jira/browse/DRILL-3120 > Project: Apache Drill > Issue Type: Bug > Components: Client - CLI >Affects Versions: 1.0.0 > Environment: Windows 8.1 VM, JDK 1.7.0_79 >Reporter: Kristine Hahn >Assignee: Aditya Kishore > Fix For: 1.1.0 > > > Install drill snapshot dated 5/15. > Double click sqlline.bat. > Output is: > DRILL_ARGS - "" > HADOOP_HOME not detected... > HBASE_HOME not detected... > Calculating Drill classpath... > Error setting configuration: isolation: java.lang.NullPointerException > apache drill 1.0.0 > "a drill is a terrible thing to waste" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2526) Creating a JDBC connection can take upto 5 seconds
[ https://issues.apache.org/jira/browse/DRILL-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-2526: - Assignee: Sudheesh Katkam > Creating a JDBC connection can take upto 5 seconds > -- > > Key: DRILL-2526 > URL: https://issues.apache.org/jira/browse/DRILL-2526 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Affects Versions: 0.8.0 > Environment: RHEL 6.4 >Reporter: Kunal Khatua >Assignee: Sudheesh Katkam > Fix For: 1.2.0 > > > Opening a JDBC connection to Drill takes unusually long. When the JVM opens > the connection one after another, the time appears to be linear with a very > small delta for each additional connection being opened. However, the initial > connection cost is very high. > This is an example of various Client JVMs opening an increasing number of > connections (source: Concurrency Testing) > concurrent_f1b59ed_SF100_20150321_1621.out:2015-03-21 16:22:38 [main] INFO > PipSQuawk initConnPool - Made 1 connections to DB in 5.309 sec > concurrent_f1b59ed_SF100_20150321_1644.out:2015-03-21 16:45:15 [main] INFO > PipSQuawk initConnPool - Made 2 connections to DB in 4.683 sec > concurrent_f1b59ed_SF100_20150321_1716.out:2015-03-21 17:17:00 [main] INFO > PipSQuawk initConnPool - Made 4 connections to DB in 4.618 sec > concurrent_f1b59ed_SF100_20150321_1807.out:2015-03-21 18:08:11 [main] INFO > PipSQuawk initConnPool - Made 8 connections to DB in 5.174 sec > concurrent_f1b59ed_SF100_20150321_1943.out:2015-03-21 19:44:13 [main] INFO > PipSQuawk initConnPool - Made 12 connections to DB in 5.318 sec > concurrent_f1b59ed_SF100_20150321_2107.out:2015-03-21 21:08:40 [main] INFO > PipSQuawk initConnPool - Made 16 connections to DB in 5.559 sec -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2526) Creating a JDBC connection can take upto 5 seconds
[ https://issues.apache.org/jira/browse/DRILL-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-2526: - Fix Version/s: (was: 1.1.0) 1.2.0 > Creating a JDBC connection can take upto 5 seconds > -- > > Key: DRILL-2526 > URL: https://issues.apache.org/jira/browse/DRILL-2526 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Affects Versions: 0.8.0 > Environment: RHEL 6.4 >Reporter: Kunal Khatua > Fix For: 1.2.0 > > > Opening a JDBC connection to Drill takes unusually long. When the JVM opens > the connection one after another, the time appears to be linear with a very > small delta for each additional connection being opened. However, the initial > connection cost is very high. > This is an example of various Client JVMs opening an increasing number of > connections (source: Concurrency Testing) > concurrent_f1b59ed_SF100_20150321_1621.out:2015-03-21 16:22:38 [main] INFO > PipSQuawk initConnPool - Made 1 connections to DB in 5.309 sec > concurrent_f1b59ed_SF100_20150321_1644.out:2015-03-21 16:45:15 [main] INFO > PipSQuawk initConnPool - Made 2 connections to DB in 4.683 sec > concurrent_f1b59ed_SF100_20150321_1716.out:2015-03-21 17:17:00 [main] INFO > PipSQuawk initConnPool - Made 4 connections to DB in 4.618 sec > concurrent_f1b59ed_SF100_20150321_1807.out:2015-03-21 18:08:11 [main] INFO > PipSQuawk initConnPool - Made 8 connections to DB in 5.174 sec > concurrent_f1b59ed_SF100_20150321_1943.out:2015-03-21 19:44:13 [main] INFO > PipSQuawk initConnPool - Made 12 connections to DB in 5.318 sec > concurrent_f1b59ed_SF100_20150321_2107.out:2015-03-21 21:08:40 [main] INFO > PipSQuawk initConnPool - Made 16 connections to DB in 5.559 sec -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DRILL-3307) Query with window function runs out of memory
[
https://issues.apache.org/jira/browse/DRILL-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590909#comment-14590909
]
Victoria Markman edited comment on DRILL-3307 at 6/18/15 12:33 AM:
---
It is not the same as https://issues.apache.org/jira/browse/DRILL-3265 ?
Abhishek, can I please either get query profile or get access to your cluster
to check it out ? Thanks !
was (Author: vicky):
It is not the same as https://issues.apache.org/jira/browse/DRILL-3265 ?
> Query with window function runs out of memory
> -
>
> Key: DRILL-3307
> URL: https://issues.apache.org/jira/browse/DRILL-3307
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.1.0
> Environment: Data set: TPC-DS SF 100 Parquet
> Number of Nodes: 4
>Reporter: Abhishek Girish
>Assignee: Deneche A. Hakim
> Attachments: drillbit.log.txt
>
>
> Query with window function runs out of memory:
> {code:sql}
> SELECT SUM(ss.ss_net_paid_inc_tax) OVER (PARTITION BY ss.ss_store_sk) AS
> TotalSpend FROM store_sales ss ORDER BY 1 LIMIT 20;
> java.lang.RuntimeException: java.sql.SQLException: RESOURCE ERROR: One or
> more nodes ran out of memory while executing the query.
> Fragment 3:0
> [Error Id: 9af19064-9175-46a4-b557-714d1c77cd76 on abhi6.qa.lab:31010]
> at sqlline.IncrementalRows.hasNext(IncrementalRows.java:73)
> at
> sqlline.TableOutputFormat$ResizingRowsProvider.next(TableOutputFormat.java:85)
> at sqlline.TableOutputFormat.print(TableOutputFormat.java:116)
> at sqlline.SqlLine.print(SqlLine.java:1583)
> at sqlline.Commands.execute(Commands.java:852)
> at sqlline.Commands.sql(Commands.java:751)
> at sqlline.SqlLine.dispatch(SqlLine.java:738)
> at sqlline.SqlLine.begin(SqlLine.java:612)
> at sqlline.SqlLine.start(SqlLine.java:366)
> at sqlline.SqlLine.main(SqlLine.java:259)
> {code}
> Plan:
> {code}
> 00-00Screen : rowType = RecordType(ANY TotalSpend): rowcount =
> 2.87997024E8, cumulative cost = {4.3487550824E9 rows, 5.7539970079068695E10
> cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9 memory}, id = 142297
> 00-01 SelectionVectorRemover : rowType = RecordType(ANY TotalSpend):
> rowcount = 2.87997024E8, cumulative cost = {4.31995538E9 rows,
> 5.751117037666869E10 cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9
> memory}, id = 142296
> 00-02Limit(fetch=[20]) : rowType = RecordType(ANY TotalSpend):
> rowcount = 2.87997024E8, cumulative cost = {4.031958356E9 rows,
> 5.722317335266869E10 cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9
> memory}, id = 142295
> 00-03 SingleMergeExchange(sort0=[0 ASC]) : rowType = RecordType(ANY
> TotalSpend): rowcount = 2.87997024E8, cumulative cost = {4.031958336E9 rows,
> 5.722317327266869E10 cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9
> memory}, id = 142294
> 01-01SelectionVectorRemover : rowType = RecordType(ANY
> TotalSpend): rowcount = 2.87997024E8, cumulative cost = {3.743961312E9 rows,
> 5.261522088866869E10 cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9
> memory}, id = 142293
> 01-02 TopN(limit=[20]) : rowType = RecordType(ANY TotalSpend):
> rowcount = 2.87997024E8, cumulative cost = {3.455964288E9 rows,
> 5.232722386466869E10 cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9
> memory}, id = 142292
> 01-03Project(TotalSpend=[$0]) : rowType = RecordType(ANY
> TotalSpend): rowcount = 2.87997024E8, cumulative cost = {3.167967264E9 rows,
> 4.734841414759049E10 cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9
> memory}, id = 142291
> 01-04 HashToRandomExchange(dist0=[[$0]]) : rowType =
> RecordType(ANY TotalSpend, ANY E_X_P_R_H_A_S_H_F_I_E_L_D): rowcount =
> 2.87997024E8, cumulative cost = {3.167967264E9 rows, 4.734841414759049E10
> cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9 memory}, id = 142290
> 02-01UnorderedMuxExchange : rowType = RecordType(ANY
> TotalSpend, ANY E_X_P_R_H_A_S_H_F_I_E_L_D): rowcount = 2.87997024E8,
> cumulative cost = {2.87997024E9 rows, 4.274046176359049E10 cpu, 0.0 io,
> 3.538907430912E12 network, 4.607952384E9 memory}, id = 142289
> 03-01 Project(TotalSpend=[$0],
> E_X_P_R_H_A_S_H_F_I_E_L_D=[castInt(hash64AsDouble($0))]) : rowType =
> RecordType(ANY TotalSpend, ANY E_X_P_R_H_A_S_H_F_I_E_L_D): rowcount =
> 2.87997024E8, cumulative cost = {2.591973216E9 rows, 4.245246473959049E10
> cpu, 0.0 io, 3.538907430912E12 network, 4.607952384E9 memory}, id = 142288
> 03-02Project(TotalSpend=[CASE(>($2, 0), CAST($3):ANY,
> null)]) : rowType = RecordType(ANY TotalSpend): rowcount = 2.87997024E8,
>
[jira] [Commented] (DRILL-3307) Query with window function runs out of memory
[
https://issues.apache.org/jira/browse/DRILL-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590909#comment-14590909
]
Victoria Markman commented on DRILL-3307:
-
It is not the same as https://issues.apache.org/jira/browse/DRILL-3265 ?
> Query with window function runs out of memory
> -
>
> Key: DRILL-3307
> URL: https://issues.apache.org/jira/browse/DRILL-3307
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.1.0
> Environment: Data set: TPC-DS SF 100 Parquet
> Number of Nodes: 4
>Reporter: Abhishek Girish
>Assignee: Deneche A. Hakim
> Attachments: drillbit.log.txt
>
>
> Query with window function runs out of memory:
> {code:sql}
> SELECT SUM(ss.ss_net_paid_inc_tax) OVER (PARTITION BY ss.ss_store_sk) AS
> TotalSpend FROM store_sales ss ORDER BY 1 LIMIT 20;
> java.lang.RuntimeException: java.sql.SQLException: RESOURCE ERROR: One or
> more nodes ran out of memory while executing the query.
> Fragment 3:0
> [Error Id: 9af19064-9175-46a4-b557-714d1c77cd76 on abhi6.qa.lab:31010]
> at sqlline.IncrementalRows.hasNext(IncrementalRows.java:73)
> at
> sqlline.TableOutputFormat$ResizingRowsProvider.next(TableOutputFormat.java:85)
> at sqlline.TableOutputFormat.print(TableOutputFormat.java:116)
> at sqlline.SqlLine.print(SqlLine.java:1583)
> at sqlline.Commands.execute(Commands.java:852)
> at sqlline.Commands.sql(Commands.java:751)
> at sqlline.SqlLine.dispatch(SqlLine.java:738)
> at sqlline.SqlLine.begin(SqlLine.java:612)
> at sqlline.SqlLine.start(SqlLine.java:366)
> at sqlline.SqlLine.main(SqlLine.java:259)
> {code}
> Plan:
> {code}
> 00-00Screen : rowType = RecordType(ANY TotalSpend): rowcount =
> 2.87997024E8, cumulative cost = {4.3487550824E9 rows, 5.7539970079068695E10
> cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9 memory}, id = 142297
> 00-01 SelectionVectorRemover : rowType = RecordType(ANY TotalSpend):
> rowcount = 2.87997024E8, cumulative cost = {4.31995538E9 rows,
> 5.751117037666869E10 cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9
> memory}, id = 142296
> 00-02Limit(fetch=[20]) : rowType = RecordType(ANY TotalSpend):
> rowcount = 2.87997024E8, cumulative cost = {4.031958356E9 rows,
> 5.722317335266869E10 cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9
> memory}, id = 142295
> 00-03 SingleMergeExchange(sort0=[0 ASC]) : rowType = RecordType(ANY
> TotalSpend): rowcount = 2.87997024E8, cumulative cost = {4.031958336E9 rows,
> 5.722317327266869E10 cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9
> memory}, id = 142294
> 01-01SelectionVectorRemover : rowType = RecordType(ANY
> TotalSpend): rowcount = 2.87997024E8, cumulative cost = {3.743961312E9 rows,
> 5.261522088866869E10 cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9
> memory}, id = 142293
> 01-02 TopN(limit=[20]) : rowType = RecordType(ANY TotalSpend):
> rowcount = 2.87997024E8, cumulative cost = {3.455964288E9 rows,
> 5.232722386466869E10 cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9
> memory}, id = 142292
> 01-03Project(TotalSpend=[$0]) : rowType = RecordType(ANY
> TotalSpend): rowcount = 2.87997024E8, cumulative cost = {3.167967264E9 rows,
> 4.734841414759049E10 cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9
> memory}, id = 142291
> 01-04 HashToRandomExchange(dist0=[[$0]]) : rowType =
> RecordType(ANY TotalSpend, ANY E_X_P_R_H_A_S_H_F_I_E_L_D): rowcount =
> 2.87997024E8, cumulative cost = {3.167967264E9 rows, 4.734841414759049E10
> cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9 memory}, id = 142290
> 02-01UnorderedMuxExchange : rowType = RecordType(ANY
> TotalSpend, ANY E_X_P_R_H_A_S_H_F_I_E_L_D): rowcount = 2.87997024E8,
> cumulative cost = {2.87997024E9 rows, 4.274046176359049E10 cpu, 0.0 io,
> 3.538907430912E12 network, 4.607952384E9 memory}, id = 142289
> 03-01 Project(TotalSpend=[$0],
> E_X_P_R_H_A_S_H_F_I_E_L_D=[castInt(hash64AsDouble($0))]) : rowType =
> RecordType(ANY TotalSpend, ANY E_X_P_R_H_A_S_H_F_I_E_L_D): rowcount =
> 2.87997024E8, cumulative cost = {2.591973216E9 rows, 4.245246473959049E10
> cpu, 0.0 io, 3.538907430912E12 network, 4.607952384E9 memory}, id = 142288
> 03-02Project(TotalSpend=[CASE(>($2, 0), CAST($3):ANY,
> null)]) : rowType = RecordType(ANY TotalSpend): rowcount = 2.87997024E8,
> cumulative cost = {2.303976192E9 rows, 4.130047664359049E10 cpu, 0.0 io,
> 3.538907430912E12 network, 4.607952384E9 memory}, id = 142287
> 03-03 Window(window#0=[window(partition {1} order by
> [] range between UNBOUNDED PRECED
[jira] [Assigned] (DRILL-3294) False schema change exception in CTAS with AVG window function
[
https://issues.apache.org/jira/browse/DRILL-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinfeng Ni reassigned DRILL-3294:
-
Assignee: Jinfeng Ni (was: Chris Westin)
> False schema change exception in CTAS with AVG window function
> --
>
> Key: DRILL-3294
> URL: https://issues.apache.org/jira/browse/DRILL-3294
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Jinfeng Ni
> Labels: window_function
> Fix For: 1.1.0
>
>
> This bug could be related to DRILL-3293, but since it's a different function
> and different symptom, I'm filing a new one.
> {code}
> 0: jdbc:drill:schema=dfs> create table wf_t1(a1) as select avg(a1)
> over(partition by a1) from t1;
> Error: SYSTEM ERROR: org.apache.drill.exec.exception.SchemaChangeException:
> Failure while trying to materialize incoming schema. Errors:
>
> Error in expression at index -1. Error: Missing function implementation:
> [castTINYINT(NULL-OPTIONAL)]. Full expression: --UNKNOWN EXPRESSION--..
> Fragment 0:0
> [Error Id: 1ca5af3a-0ea7-4b75-b493-74f6404d4894 on atsqa4-133.qa.lab:31010]
> (state=,code=0)
> {code}
> Query works correctly by itself:
> {code}
> 0: jdbc:drill:schema=dfs> select avg(a1) over(partition by a1) from t1;
> +-+
> | EXPR$0 |
> +-+
> | 1 |
> | 2 |
> | 3 |
> | 4 |
> | 5 |
> | 6 |
> | 7 |
> | 9 |
> | 10 |
> | null|
> +-+
> 10 rows selected (0.181 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3294) False schema change exception in CTAS with AVG window function
[
https://issues.apache.org/jira/browse/DRILL-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinfeng Ni updated DRILL-3294:
--
Component/s: (was: Execution - Relational Operators)
Query Planning & Optimization
> False schema change exception in CTAS with AVG window function
> --
>
> Key: DRILL-3294
> URL: https://issues.apache.org/jira/browse/DRILL-3294
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Chris Westin
> Labels: window_function
> Fix For: 1.1.0
>
>
> This bug could be related to DRILL-3293, but since it's a different function
> and different symptom, I'm filing a new one.
> {code}
> 0: jdbc:drill:schema=dfs> create table wf_t1(a1) as select avg(a1)
> over(partition by a1) from t1;
> Error: SYSTEM ERROR: org.apache.drill.exec.exception.SchemaChangeException:
> Failure while trying to materialize incoming schema. Errors:
>
> Error in expression at index -1. Error: Missing function implementation:
> [castTINYINT(NULL-OPTIONAL)]. Full expression: --UNKNOWN EXPRESSION--..
> Fragment 0:0
> [Error Id: 1ca5af3a-0ea7-4b75-b493-74f6404d4894 on atsqa4-133.qa.lab:31010]
> (state=,code=0)
> {code}
> Query works correctly by itself:
> {code}
> 0: jdbc:drill:schema=dfs> select avg(a1) over(partition by a1) from t1;
> +-+
> | EXPR$0 |
> +-+
> | 1 |
> | 2 |
> | 3 |
> | 4 |
> | 5 |
> | 6 |
> | 7 |
> | 9 |
> | 10 |
> | null|
> +-+
> 10 rows selected (0.181 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3294) False schema change exception in CTAS with AVG window function
[
https://issues.apache.org/jira/browse/DRILL-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinfeng Ni updated DRILL-3294:
--
Fix Version/s: 1.1.0
> False schema change exception in CTAS with AVG window function
> --
>
> Key: DRILL-3294
> URL: https://issues.apache.org/jira/browse/DRILL-3294
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Chris Westin
> Labels: window_function
> Fix For: 1.1.0
>
>
> This bug could be related to DRILL-3293, but since it's a different function
> and different symptom, I'm filing a new one.
> {code}
> 0: jdbc:drill:schema=dfs> create table wf_t1(a1) as select avg(a1)
> over(partition by a1) from t1;
> Error: SYSTEM ERROR: org.apache.drill.exec.exception.SchemaChangeException:
> Failure while trying to materialize incoming schema. Errors:
>
> Error in expression at index -1. Error: Missing function implementation:
> [castTINYINT(NULL-OPTIONAL)]. Full expression: --UNKNOWN EXPRESSION--..
> Fragment 0:0
> [Error Id: 1ca5af3a-0ea7-4b75-b493-74f6404d4894 on atsqa4-133.qa.lab:31010]
> (state=,code=0)
> {code}
> Query works correctly by itself:
> {code}
> 0: jdbc:drill:schema=dfs> select avg(a1) over(partition by a1) from t1;
> +-+
> | EXPR$0 |
> +-+
> | 1 |
> | 2 |
> | 3 |
> | 4 |
> | 5 |
> | 6 |
> | 7 |
> | 9 |
> | 10 |
> | null|
> +-+
> 10 rows selected (0.181 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DRILL-2763) [umbrella] Implement INFORMATION_SCHEMA.COLUMNS enough for relevant tools
[
https://issues.apache.org/jira/browse/DRILL-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) resolved DRILL-2763.
---
Resolution: Fixed
Superseded by combination of DRILL-3216 (fixes) and DRILL-3308 (remainder).
> [umbrella] Implement INFORMATION_SCHEMA.COLUMNS enough for relevant tools
> -
>
> Key: DRILL-2763
> URL: https://issues.apache.org/jira/browse/DRILL-2763
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Information Schema
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: 1.1.0
>
>
> \[Edit: Problems marked with "\[3216]" were fixed by DRILL-3216.]
> Note: This JIRA report is/was intended in part for for tracking specific
> noticed differences between Drill and standard SQL (not necessarily
> differences we've already decided to fix), and also in part as a reminder of
> this likelihood of running into problems with tools that we care about (even
> that set of problems isn't known now).
> Drill's {{INFORMATION_SCHEMA.COLUMNS}} is not compliant with SQL:2011.
> *A. {{COLUMNS}} columns existing in Drill that are not compliant with
> standard SQL*:
> 1. *TDB*: {{TABLE_NAME}} holds the original form of the identifier but
> _might_ need to be uppercased here to be compliant (or possibly internal
> matching queries (e.g., for JDBC's getColumns(...)) could be
> case-insensitive).
> 2. *TDB*: {{COLUMN_NAME}} holds the original form of the identifier but
> _might_ need to be uppercased here to be compliant (or possibly internal
> matching queries (e.g., for JDBC's getColumns(...)) could be
> case-insensitive).
> 3. \[3216] {{ORDINAL_POSITION}} values are zero-based rather than being
> one-based.
> 4. \[3216] {{CHARACTER_MAXIMUM_LENGTH}}, {{NUMERIC_PRECISION_RADIX}},
> {{NUMERIC_SCALE}}, and {{NUMERIC_PRECISION}} use {{-1}} instead of {{NULL}}
> for the "not-applicable" case.
> 5. \[3216] {{NUMERIC_PRECISION}} for non-{{DECIMAL}}/{{NUMERIC}} exact
> numeric types (e.g., {{INTEGER}}) and approximate numeric types (e.g.,
> {{DOUBLE}}) is {{-1}} (logical null) instead of the specified values.
> 6. \[3216] {{NUMERIC_SCALE}} for non-{{DECIMAL}}/{{NUMERIC}} exact numeric
> types is {{-1}} instead of {{0}}.
> 7. \[3216] {{NUMERIC_SCALE}} for approximate numeric types is {{-1}} instead
> of the number of bits of precision (24 and 53(?)).
> 8. \[3216] {{NUMERIC_PRECISION_RADIX}} for integral exact numeric types is
> {{-1}} instead of {{10}}.
> 9. \[3216] {{NUMERIC_PRECISION_RADIX}} for approximate exact numeric types is
> {{-1}} instead of {{2}}.
> 10. \[3216] {{CHARACTER_MAXIMUM_LENGTH}} for types {{CHAR}}, {{BINARY}}, and
> {{VAR BINARY}} is {{-1}} instead of the corresponding length.
> 11. \[3216] {{DATA_TYPE}} values for {{INTERVAL}} with {{YEAR}} and/or
> {{MONTH}} and for {{INTERVAL}} with {{DAY}}, {{HOUR}}, {{MINUTE}}, and/or
> {{SECOND}} are "{{INTERVAL_YEAR_MONTH}}" and "{{INTERVAL_DATA_TIME}}",
> respectively, instead of the data type name "{{INTERVAL}}".
> 12. \[3216] {{DATA_TYPE}} values for non-atomic types seem to be type
> descriptors ({{}} syntax; e.g., "{{VARCHAR(65536) ARRAY}}")
> instead of just data type names (e.g., "{{ARRAY}}").
> *B. Standard {{COLUMNS}} columns that don't exist in Drill and that probably
> are more relevant*:
> 1. \[3216] {{CHARACTER_OCTET_LENGTH}} does not exist. (Drill's JDBC driver
> needs to return this, and currently tries to compute it itself.)
> 2. \[3216] {{DATETIME_PRECISION}} does not exist. (Drill's JDBC driver
> probably needs it to compute its {{getColumns()}}'s {{COLUMN_SIZE}}
> correctly.)
> 3. \[3216] {{INTERVAL_TYPE}} does not exist. (Drill's JDBC driver needs this
> to compute its {{getColumns()}}'s {{COLUMN_SIZE}} correctly once
> {{COLUMNS.DATA_TYPE}} is correct.}
> 4. \[3216] {{INTERVAL_PRECISION}} does not exist. (Drill's JDBC driver needs
> this to compute its {{getColumns()}}'s {{COLUMN_SIZE}} correctly.)
> \[TBD]:
> 5. {{MAXIMUM_CARDINALITY}} does not exist. (This might be relevant for
> JDBC's {{getColumns()}}'s {{COLUMN_SIZE}}.)
> *C. Standard {{COLUMNS}} columns that don't exist in Drill but are less
> likely to be relevant (listed for completeness)*:
> - \[3216] {{COLUMN_DEFAULT}}
> - {{CHARACTER_SET_CATALOG}}
> - {{CHARACTER_SET_SCHEMA}}
> - {{CHARACTER_SET_NAME}}
> - {{COLLATION_CATALOG}}
> - {{COLLATION_SCHEMA}}
> - {{COLLATION_NAME}}
> - {{DOMAIN_CATALOG}}
> - {{DOMAIN_SCHEMA}}
> - {{DOMAIN_NAME}}
> - {{UDT_CATALOG}}
> - {{UDT_SCHEMA}}
> - {{UDT_NAME}}
> - {{SCOPE_CATALOG}}
> - {{SCOPE_SCHEMA}}
> - {{SCOPE_NAME}}
> - {{DTD_IDENTIFIER}}
> - {{IS_SELF_REFERENCING}}
> - {{IS_IDENTITY}}
> - {{IDENTITY_GENERATION}}
> - {{IDENTITY_START}}
> - {{IDENTITY_INCREMENT}}
> - {{IDENTITY_MAXIMUM}}
>
[jira] [Commented] (DRILL-3308) Revisit INFORMATION_SCHEMA.COLUMNS's SQL compliance.
[
https://issues.apache.org/jira/browse/DRILL-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590889#comment-14590889
]
Daniel Barclay (Drill) commented on DRILL-3308:
---
Replaces DRILL-2763 to cover the parts (of DRILL-2763) not addressed (fixed) by
DRILL-3216.
> Revisit INFORMATION_SCHEMA.COLUMNS's SQL compliance.
>
>
> Key: DRILL-3308
> URL: https://issues.apache.org/jira/browse/DRILL-3308
> Project: Apache Drill
> Issue Type: Bug
> Components: Metadata
>Reporter: Daniel Barclay (Drill)
>Assignee: Steven Phillips
>
> At some point, review the compliance with the SQL specification of Drill's
> INFORMATION_SCHEMA.COLUMNS table.
> {{TABLE_NAME}} holds the original form of the identifier but _might_ need to
> be uppercased here to be compliant (or possibly internal matching queries
> (e.g., for JDBC's getColumns(...)) could be case-insensitive).
> {{COLUMN_NAME}} holds the original form of the identifier but _might_ need to
> be uppercased here to be compliant (or possibly internal matching queries
> (e.g., for JDBC's getColumns(...)) could be case-insensitive).
> {{MAXIMUM_CARDINALITY}} does not exist.
> The following columns do not exist:
> - {{CHARACTER_SET_CATALOG}}
> - {{CHARACTER_SET_SCHEMA}}
> - {{CHARACTER_SET_NAME}}
> - {{COLLATION_CATALOG}}
> - {{COLLATION_SCHEMA}}
> - {{COLLATION_NAME}}
> - {{DOMAIN_CATALOG}}
> - {{DOMAIN_SCHEMA}}
> - {{DOMAIN_NAME}}
> - {{UDT_CATALOG}}
> - {{UDT_SCHEMA}}
> - {{UDT_NAME}}
> - {{SCOPE_CATALOG}}
> - {{SCOPE_SCHEMA}}
> - {{SCOPE_NAME}}
> - {{DTD_IDENTIFIER}}
> - {{IS_SELF_REFERENCING}}
> - {{IS_IDENTITY}}
> - {{IDENTITY_GENERATION}}
> - {{IDENTITY_START}}
> - {{IDENTITY_INCREMENT}}
> - {{IDENTITY_MAXIMUM}}
> - {{IDENTITY_MINIMUM}}
> - {{IDENTITY_CYCLE}}
> - {{IS_GENERATED}}
> - {{GENERATION_EXPRESSION}}
> - {{IS_SYSTEM_TIME_PERIOD_START}}
> - {{IS_SYSTEM_TIME_PERIOD_END}}
> - {{SYSTEM_TIME_PERIOD_TIMESTAMP_GENERATION}}
> - {{IS_UPDATABLE}}
> - {{DECLARED_DATA_TYPE}}
> - {{DECLARED_NUMERIC_PRECISION}}
> - {{DECLARED_NUMERIC_SCALE}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-3298) Wrong result with SUM window function and order by without partition by in the OVER clause
[
https://issues.apache.org/jira/browse/DRILL-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590887#comment-14590887
]
Aman Sinha commented on DRILL-3298:
---
I have a uploaded a patch for this to review board:
https://reviews.apache.org/r/35584/
[~jni] could you pls review ? I am still in the process of running all
regression tests.
> Wrong result with SUM window function and order by without partition by in
> the OVER clause
> --
>
> Key: DRILL-3298
> URL: https://issues.apache.org/jira/browse/DRILL-3298
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Aman Sinha
>Priority: Critical
> Labels: window_function
> Fix For: 1.1.0
>
> Attachments: DRILL-3298.1.patch.txt, j1.tar, test.res
>
>
> This query returns incorrect result when planner.slice_target = 1
> {code}
> select
> j1.c_integer,
> sum(j1.c_integer) over w
> from j1
> window w as (order by c_integer desc)
> order by
> 1, 2;
> {code}
> Query plan with planner.slice_target = 1
> {noformat}
> 00-01 Project(c_integer=[$0], EXPR$1=[$1])
> 00-02SingleMergeExchange(sort0=[0 ASC], sort1=[1 ASC])
> 01-01 SelectionVectorRemover
> 01-02Sort(sort0=[$0], sort1=[$1], dir0=[ASC], dir1=[ASC])
> 01-03 Project(c_integer=[$0], EXPR$1=[$1])
> 01-04HashToRandomExchange(dist0=[[$0]], dist1=[[$1]])
> 02-01 UnorderedMuxExchange
> 03-01Project(c_integer=[$0], EXPR$1=[$1],
> E_X_P_R_H_A_S_H_F_I_E_L_D=[castInt(hash64AsDouble($1, hash64AsDouble($0)))])
> 03-02 Project(c_integer=[$0], EXPR$1=[CASE(>($1, 0),
> CAST($2):ANY, null)])
> 03-03Window(window#0=[window(partition {} order by [0
> DESC] range between UNBOUNDED PRECEDING and CURRENT ROW aggs [COUNT($0),
> $SUM0($0)])])
> 03-04 SelectionVectorRemover
> 03-05Sort(sort0=[$0], dir0=[DESC])
> 03-06 Scan(groupscan=[ParquetGroupScan
> [entries=[ReadEntryWithPath [path=maprfs:///drill/testdata/subqueries/j1]],
> selectionRoot=/drill/testdata/subqueries/j1, numFiles=1,
> columns=[`c_integer`]]])
> {noformat}
> Query plan with planner.slice_target = 10;
> {noformat}
> 00-01 Project(c_integer=[$0], EXPR$1=[$1])
> 00-02SelectionVectorRemover
> 00-03 Sort(sort0=[$0], sort1=[$1], dir0=[ASC], dir1=[ASC])
> 00-04Project(c_integer=[$0], EXPR$1=[CASE(>($1, 0), CAST($2):ANY,
> null)])
> 00-05 Window(window#0=[window(partition {} order by [0 DESC]
> range between UNBOUNDED PRECEDING and CURRENT ROW aggs [COUNT($0),
> $SUM0($0)])])
> 00-06SelectionVectorRemover
> 00-07 Sort(sort0=[$0], dir0=[DESC])
> 00-08Scan(groupscan=[ParquetGroupScan
> [entries=[ReadEntryWithPath [path=maprfs:///drill/testdata/subqueries/j1]],
> selectionRoot=/drill/testdata/subqueries/j1, numFiles=1,
> columns=[`c_integer`]]])
> {noformat}
> Attached:
> * table j1
> * test.res - result generated with postgres
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-3308) Revisit INFORMATION_SCHEMA.COLUMNS's SQL compliance.
Daniel Barclay (Drill) created DRILL-3308:
-
Summary: Revisit INFORMATION_SCHEMA.COLUMNS's SQL compliance.
Key: DRILL-3308
URL: https://issues.apache.org/jira/browse/DRILL-3308
Project: Apache Drill
Issue Type: Bug
Components: Metadata
Reporter: Daniel Barclay (Drill)
Assignee: Steven Phillips
At some point, review the compliance with the SQL specification of Drill's
INFORMATION_SCHEMA.COLUMNS table.
{{TABLE_NAME}} holds the original form of the identifier but _might_ need to be
uppercased here to be compliant (or possibly internal matching queries (e.g.,
for JDBC's getColumns(...)) could be case-insensitive).
{{COLUMN_NAME}} holds the original form of the identifier but _might_ need to
be uppercased here to be compliant (or possibly internal matching queries
(e.g., for JDBC's getColumns(...)) could be case-insensitive).
{{MAXIMUM_CARDINALITY}} does not exist.
The following columns do not exist:
- {{CHARACTER_SET_CATALOG}}
- {{CHARACTER_SET_SCHEMA}}
- {{CHARACTER_SET_NAME}}
- {{COLLATION_CATALOG}}
- {{COLLATION_SCHEMA}}
- {{COLLATION_NAME}}
- {{DOMAIN_CATALOG}}
- {{DOMAIN_SCHEMA}}
- {{DOMAIN_NAME}}
- {{UDT_CATALOG}}
- {{UDT_SCHEMA}}
- {{UDT_NAME}}
- {{SCOPE_CATALOG}}
- {{SCOPE_SCHEMA}}
- {{SCOPE_NAME}}
- {{DTD_IDENTIFIER}}
- {{IS_SELF_REFERENCING}}
- {{IS_IDENTITY}}
- {{IDENTITY_GENERATION}}
- {{IDENTITY_START}}
- {{IDENTITY_INCREMENT}}
- {{IDENTITY_MAXIMUM}}
- {{IDENTITY_MINIMUM}}
- {{IDENTITY_CYCLE}}
- {{IS_GENERATED}}
- {{GENERATION_EXPRESSION}}
- {{IS_SYSTEM_TIME_PERIOD_START}}
- {{IS_SYSTEM_TIME_PERIOD_END}}
- {{SYSTEM_TIME_PERIOD_TIMESTAMP_GENERATION}}
- {{IS_UPDATABLE}}
- {{DECLARED_DATA_TYPE}}
- {{DECLARED_NUMERIC_PRECISION}}
- {{DECLARED_NUMERIC_SCALE}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DRILL-2420) [umbrella] Identify, fix DatabaseMetaData.getColumns() bugs
[
https://issues.apache.org/jira/browse/DRILL-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) resolved DRILL-2420.
---
Resolution: Fixed
> [umbrella] Identify, fix DatabaseMetaData.getColumns() bugs
> ---
>
> Key: DRILL-2420
> URL: https://issues.apache.org/jira/browse/DRILL-2420
> Project: Apache Drill
> Issue Type: Task
> Components: Client - JDBC, Metadata
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: 1.1.0
>
>
> Drill's implementation of {{DatabaseMetaData.getColumns(...)}} (currently at
> {{org.apache.drill.jdbc.MetaImpl.getColumns()}}) doesn't match the JDBC
> specification (the Javadoc documentation for
> {{DatabaseMetaData.getColumns(...)}} (as of Java 7)). In the returned
> {{ResultSet}}:
> 1. -Column {{DATA_TYPE}} is of type {{VARCHAR}} (containing the type name)
> rather than being of type {{INTEGER}} (containing values per
> {{java.sql.Types.*}}).- \[Fixed by DRILL-2128.\]
> 2. -Column {{TYPE_NAME}} is missing.- \[Fixed by DRILL-2128.\]
> 3. -Column {{COLUMN_SIZE}} is missing.- \[Fixed by DRILL-2465.\]
> 4. -(Columns after {{DATA_TYPE}} are at incorrect indexes.)- \[Fixed by
> DRILL-2465.\]
> 5. -Column {{DECIMAL_DIGITS}} is misnamed {{DECIMAL_PRECISION}}.- \[Fixed by
> DRILL-2465.\]
> 6. -Column {{REMARKS}} is an empty string, but probably should be {{NULL}}.-
> \[Fixed by DRILL-2465.\]
> 7. -Column {{COLUMN_DEF}} is an empty string, but probably should be
> {{NULL}}.- \[Fixed by DRILL-2465.\]
> 8. -Column {{CHAR_OCTET_LENGTH}} is always {{4}}, but should be "the maximum
> number of bytes in the _column_" for character types.- \[Fixed by
> DRILL-2465.\]
> 8.5 Column {{IS_NULLABLE}} seems to always return 'NO'.
> 9. -Column {{ORDINAL_POSITION}} is always {{1}}, but should be the index of
> the specific column.- \[Fixed by DRILL-2465.\]
> 10. -Column {{IS_NULLABLE}} is {{'YES'}}, which doesn't seem to correspond to
> the value for {{NULLABLE}} ({{DatabaseMetaData.columnNullableUnknown}}).-
> \[Fixed (unidentified change).\`]
> 11. -Column {{SCOPE_CATALOG}} is an empty string, but should be {{NULL}}.-
> \[Fixed by DRILL-2465.\]
> 12. -Column {{SCOPE_SCHEMA}} is an empty string, but should be {{NULL}}.-
> \[Fixed by DRILL-2465.\]
> 13. -Column {{SCOPE_TABLE}} is an empty string, but should be {{NULL}}.-
> \[Fixed by DRILL-2465.\]
> 14. -Column {{SOURCE_DATA_TYPE}} is an empty string, but should be {{NULL}}.-
> \[Fixed by DRILL-2465.\]
> Additional bugs or suspect behavior:
> - -{{DECIMAL_DIGITS}}/{{DECIMAL_PRECISION}} is {{-1}} when it should be
> {{NULL}} (when not applicable).- \[Fixed by DRILL-2465.\]
> - -{{NUM_PREC_RADIX}} is {{-1}} when it probably should be {{NULL}} (when not
> applicable).- \[Fixed by DRILL-2465.\]
> (Other columns to check:
> Re {{BUFFER_LENGTH}}, {{SQL_DATA_TYPE}}, and {{SQL_DATETIME_SUB}}: When JDBC
> says a column is not used, are there any requirements on the values (e.g.,
> being {{NULL}})?
> Re {{IS_AUTOINCREMENT}}: Do we know that a column is not auto-incremented?
> If so, the value could be {{'NO'}} rather than an empty string.
> Re {{IS_GENERATEDCOLUMN}}: Do we know that a column is not generated? If
> so, the value could be {{'NO'}} rather than an empty string.
> (Re {{NULLABLE}} : Do know whether a column is nullable or not? If so, we
> could return the specific answer rather that just saying that it's unknown.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2420) [umbrella] Identify, fix DatabaseMetaData.getColumns() bugs
[
https://issues.apache.org/jira/browse/DRILL-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2420:
--
Description:
Drill's implementation of {{DatabaseMetaData.getColumns(...)}} (currently at
{{org.apache.drill.jdbc.MetaImpl.getColumns()}}) doesn't match the JDBC
specification (the Javadoc documentation for
{{DatabaseMetaData.getColumns(...)}} (as of Java 7)). In the returned
{{ResultSet}}:
1. -Column {{DATA_TYPE}} is of type {{VARCHAR}} (containing the type name)
rather than being of type {{INTEGER}} (containing values per
{{java.sql.Types.*}}).- \[Fixed by DRILL-2128.\]
2. -Column {{TYPE_NAME}} is missing.- \[Fixed by DRILL-2128.\]
3. -Column {{COLUMN_SIZE}} is missing.- \[Fixed by DRILL-2465.\]
4. -(Columns after {{DATA_TYPE}} are at incorrect indexes.)- \[Fixed by
DRILL-2465.\]
5. -Column {{DECIMAL_DIGITS}} is misnamed {{DECIMAL_PRECISION}}.- \[Fixed by
DRILL-2465.\]
6. -Column {{REMARKS}} is an empty string, but probably should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
7. -Column {{COLUMN_DEF}} is an empty string, but probably should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
8. -Column {{CHAR_OCTET_LENGTH}} is always {{4}}, but should be "the maximum
number of bytes in the _column_" for character types.- \[Fixed by DRILL-2465.\]
8.5 Column {{IS_NULLABLE}} seems to always return 'NO'.
9. -Column {{ORDINAL_POSITION}} is always {{1}}, but should be the index of the
specific column.- \[Fixed by DRILL-2465.\]
10. -Column {{IS_NULLABLE}} is {{'YES'}}, which doesn't seem to correspond to
the value for {{NULLABLE}} ({{DatabaseMetaData.columnNullableUnknown}}).-
\[Fixed (unidentified change).\`]
11. -Column {{SCOPE_CATALOG}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
12. -Column {{SCOPE_SCHEMA}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
13. -Column {{SCOPE_TABLE}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
14. -Column {{SOURCE_DATA_TYPE}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
Additional bugs or suspect behavior:
- -{{DECIMAL_DIGITS}}/{{DECIMAL_PRECISION}} is {{-1}} when it should be
{{NULL}} (when not applicable).- \[Fixed by DRILL-2465.\]
- -{{NUM_PREC_RADIX}} is {{-1}} when it probably should be {{NULL}} (when not
applicable).- \[Fixed by DRILL-2465.\]
(Other columns to check:
Re {{BUFFER_LENGTH}}, {{SQL_DATA_TYPE}}, and {{SQL_DATETIME_SUB}}: When JDBC
says a column is not used, are there any requirements on the values (e.g.,
being {{NULL}})?
Re {{IS_AUTOINCREMENT}}: Do we know that a column is not auto-incremented? If
so, the value could be {{'NO'}} rather than an empty string.
Re {{IS_GENERATEDCOLUMN}}: Do we know that a column is not generated? If so,
the value could be {{'NO'}} rather than an empty string.
(Re {{NULLABLE}} : Do know whether a column is nullable or not? If so, we
could return the specific answer rather that just saying that it's unknown.)
was:
Drill's implementation of {{DatabaseMetaData.getColumns(...)}} (currently at
{{org.apache.drill.jdbc.MetaImpl.getColumns()}}) doesn't match the JDBC
specification (the Javadoc documentation for
{{DatabaseMetaData.getColumns(...)}} (as of Java 7)). In the returned
{{ResultSet}}:
1. -Column {{DATA_TYPE}} is of type {{VARCHAR}} (containing the type name)
rather than being of type {{INTEGER}} (containing values per
{{java.sql.Types.*}}).- \[Fixed by DRILL-2128.\]
2. -Column {{TYPE_NAME}} is missing.- \[Fixed by DRILL-2128.\]
3. -Column {{COLUMN_SIZE}} is missing.- \[Fixed by DRILL-2465.\]
4. -(Columns after {{DATA_TYPE}} are at incorrect indexes.)- \[Fixed by
DRILL-2465.\]
5. -Column {{DECIMAL_DIGITS}} is misnamed {{DECIMAL_PRECISION}}.- \[Fixed by
DRILL-2465.\]
6. -Column {{REMARKS}} is an empty string, but probably should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
7. -Column {{COLUMN_DEF}} is an empty string, but probably should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
8. -Column {{CHAR_OCTET_LENGTH}} is always {{4}}, but should be "the maximum
number of bytes in the _column_" for character types.- \[Fixed by DRILL-2465.\]
8.5 Column {{IS_NULLABLE}} seems to always return 'NO'.
9. -Column {{ORDINAL_POSITION}} is always {{1}}, but should be the index of the
specific column.- \[Fixed by DRILL-2465.\]
10. Column {{IS_NULLABLE}} is {{'YES'}}, which doesn't seem to correspond to
the value for {{NULLABLE}} ({{DatabaseMetaData.columnNullableUnknown}}).
11. -Column {{SCOPE_CATALOG}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
12. -Column {{SCOPE_SCHEMA}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
13. -Column {{SCOPE_TABLE}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
14. -Column {{SOURCE_DATA_TYPE}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
Additional bugs or suspect behavio
[jira] [Updated] (DRILL-2420) [umbrella] Identify, fix DatabaseMetaData.getColumns() bugs
[
https://issues.apache.org/jira/browse/DRILL-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2420:
--
Description:
Drill's implementation of {{DatabaseMetaData.getColumns(...)}} (currently at
{{org.apache.drill.jdbc.MetaImpl.getColumns()}}) doesn't match the JDBC
specification (the Javadoc documentation for
{{DatabaseMetaData.getColumns(...)}} (as of Java 7)). In the returned
{{ResultSet}}:
1. -Column {{DATA_TYPE}} is of type {{VARCHAR}} (containing the type name)
rather than being of type {{INTEGER}} (containing values per
{{java.sql.Types.*}}).- \[Fixed by DRILL-2128.\]
2. -Column {{TYPE_NAME}} is missing.- \[Fixed by DRILL-2128.\]
3. -Column {{COLUMN_SIZE}} is missing.- \[Fixed by DRILL-2465.\]
4. -(Columns after {{DATA_TYPE}} are at incorrect indexes.)- \[Fixed by
DRILL-2465.\]
5. -Column {{DECIMAL_DIGITS}} is misnamed {{DECIMAL_PRECISION}}.- \[Fixed by
DRILL-2465.\]
6. -Column {{REMARKS}} is an empty string, but probably should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
7. -Column {{COLUMN_DEF}} is an empty string, but probably should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
8. -Column {{CHAR_OCTET_LENGTH}} is always {{4}}, but should be "the maximum
number of bytes in the _column_" for character types.- \[Fixed by DRILL-2465.\]
8.5 Column {{IS_NULLABLE}} seems to always return 'NO'.
9. -Column {{ORDINAL_POSITION}} is always {{1}}, but should be the index of the
specific column.- \[Fixed by DRILL-2465.\]
10. Column {{IS_NULLABLE}} is {{'YES'}}, which doesn't seem to correspond to
the value for {{NULLABLE}} ({{DatabaseMetaData.columnNullableUnknown}}).
11. -Column {{SCOPE_CATALOG}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
12. -Column {{SCOPE_SCHEMA}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
13. -Column {{SCOPE_TABLE}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
14. -Column {{SOURCE_DATA_TYPE}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
Additional bugs or suspect behavior:
- -{{DECIMAL_DIGITS}}/{{DECIMAL_PRECISION}} is {{-1}} when it should be
{{NULL}} (when not applicable).- \[Fixed by DRILL-2465.\]
- -{{NUM_PREC_RADIX}} is {{-1}} when it probably should be {{NULL}} (when not
applicable).- \[Fixed by DRILL-2465.\]
(Other columns to check:
Re {{BUFFER_LENGTH}}, {{SQL_DATA_TYPE}}, and {{SQL_DATETIME_SUB}}: When JDBC
says a column is not used, are there any requirements on the values (e.g.,
being {{NULL}})?
Re {{IS_AUTOINCREMENT}}: Do we know that a column is not auto-incremented? If
so, the value could be {{'NO'}} rather than an empty string.
Re {{IS_GENERATEDCOLUMN}}: Do we know that a column is not generated? If so,
the value could be {{'NO'}} rather than an empty string.
(Re {{NULLABLE}} : Do know whether a column is nullable or not? If so, we
could return the specific answer rather that just saying that it's unknown.)
was:
Drill's implementation of {{DatabaseMetaData.getColumns(...)}} (currently at
{{org.apache.drill.jdbc.MetaImpl.getColumns()}}) doesn't match the JDBC
specification (the Javadoc documentation for
{{DatabaseMetaData.getColumns(...)}} (as of Java 7)). In the returned
{{ResultSet}}:
1. -Column {{DATA_TYPE}} is of type {{VARCHAR}} (containing the type name)
rather than being of type {{INTEGER}} (containing values per
{{java.sql.Types.*}}).- \[Fixed by DRILL-2128.\]
2. -Column {{TYPE_NAME}} is missing.- \[Fixed by DRILL-2128.\]
3. -Column {{COLUMN_SIZE}} is missing.- \[Fixed by DRILL-2465.\]
4. -(Columns after {{DATA_TYPE}} are at incorrect indexes.)- \[Fixed by
DRILL-2465.\]
5. -Column {{DECIMAL_DIGITS}} is misnamed {{DECIMAL_PRECISION}}.- \[Fixed by
DRILL-2465.\]
6. -Column {{REMARKS}} is an empty string, but probably should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
7. -Column {{COLUMN_DEF}} is an empty string, but probably should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
8. -Column {{CHAR_OCTET_LENGTH}} is always {{4}}, but should be "the maximum
number of bytes in the _column_" for character types.- \[Fixed by DRILL-2465.\]
8.5 Column {{IS_NULLABLE}} seems to always return 'NO'.
9. -Column {{ORDINAL_POSITION}} is always {{1}}, but should be the index of the
specific column.- \[Fixed by DRILL-2465.\]
10. Column {{IS_NULLABLE}} is {{'YES'}}, which doesn't seem to correspond to
the value for {{NULLABLE}} ({{DatabaseMetaData.columnNullableUnknown}}).
11. -Column {{SCOPE_CATALOG}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
12. -Column {{SCOPE_SCHEMA}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
13. -Column {{SCOPE_TABLE}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
14. -Column {{SOURCE_DATA_TYPE}} is an empty string, but should be {{NULL}}.-
\[Fixed by DRILL-2465.\]
Additional bugs or suspect behavior:
- {{DECIMAL_DIGITS}}/{{DECIMAL_PR
[jira] [Updated] (DRILL-2164) Composite vectors should rely on VectorContainer for maintaining child vectors
[ https://issues.apache.org/jira/browse/DRILL-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanifi Gunes updated DRILL-2164: Fix Version/s: (was: 1.1.0) Future > Composite vectors should rely on VectorContainer for maintaining child vectors > -- > > Key: DRILL-2164 > URL: https://issues.apache.org/jira/browse/DRILL-2164 > Project: Apache Drill > Issue Type: Sub-task > Components: Execution - Data Types >Reporter: Hanifi Gunes >Assignee: Hanifi Gunes > Fix For: Future > > > As of DRILL-1885, the logic that handles maintaining vectors is mostly > scattered and repeated across AbstractContainerVector and VectorContainer. We > should come up with an abstraction unifying vector container logic for better > code re-use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3307) Query with window function runs out of memory
[
https://issues.apache.org/jira/browse/DRILL-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Girish updated DRILL-3307:
---
Attachment: drillbit.log.txt
> Query with window function runs out of memory
> -
>
> Key: DRILL-3307
> URL: https://issues.apache.org/jira/browse/DRILL-3307
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.1.0
> Environment: Data set: TPC-DS SF 100 Parquet
> Number of Nodes: 4
>Reporter: Abhishek Girish
>Assignee: Deneche A. Hakim
> Attachments: drillbit.log.txt
>
>
> Query with window function runs out of memory:
> {code:sql}
> SELECT SUM(ss.ss_net_paid_inc_tax) OVER (PARTITION BY ss.ss_store_sk) AS
> TotalSpend FROM store_sales ss ORDER BY 1 LIMIT 20;
> java.lang.RuntimeException: java.sql.SQLException: RESOURCE ERROR: One or
> more nodes ran out of memory while executing the query.
> Fragment 3:0
> [Error Id: 9af19064-9175-46a4-b557-714d1c77cd76 on abhi6.qa.lab:31010]
> at sqlline.IncrementalRows.hasNext(IncrementalRows.java:73)
> at
> sqlline.TableOutputFormat$ResizingRowsProvider.next(TableOutputFormat.java:85)
> at sqlline.TableOutputFormat.print(TableOutputFormat.java:116)
> at sqlline.SqlLine.print(SqlLine.java:1583)
> at sqlline.Commands.execute(Commands.java:852)
> at sqlline.Commands.sql(Commands.java:751)
> at sqlline.SqlLine.dispatch(SqlLine.java:738)
> at sqlline.SqlLine.begin(SqlLine.java:612)
> at sqlline.SqlLine.start(SqlLine.java:366)
> at sqlline.SqlLine.main(SqlLine.java:259)
> {code}
> Plan:
> {code}
> 00-00Screen : rowType = RecordType(ANY TotalSpend): rowcount =
> 2.87997024E8, cumulative cost = {4.3487550824E9 rows, 5.7539970079068695E10
> cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9 memory}, id = 142297
> 00-01 SelectionVectorRemover : rowType = RecordType(ANY TotalSpend):
> rowcount = 2.87997024E8, cumulative cost = {4.31995538E9 rows,
> 5.751117037666869E10 cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9
> memory}, id = 142296
> 00-02Limit(fetch=[20]) : rowType = RecordType(ANY TotalSpend):
> rowcount = 2.87997024E8, cumulative cost = {4.031958356E9 rows,
> 5.722317335266869E10 cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9
> memory}, id = 142295
> 00-03 SingleMergeExchange(sort0=[0 ASC]) : rowType = RecordType(ANY
> TotalSpend): rowcount = 2.87997024E8, cumulative cost = {4.031958336E9 rows,
> 5.722317327266869E10 cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9
> memory}, id = 142294
> 01-01SelectionVectorRemover : rowType = RecordType(ANY
> TotalSpend): rowcount = 2.87997024E8, cumulative cost = {3.743961312E9 rows,
> 5.261522088866869E10 cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9
> memory}, id = 142293
> 01-02 TopN(limit=[20]) : rowType = RecordType(ANY TotalSpend):
> rowcount = 2.87997024E8, cumulative cost = {3.455964288E9 rows,
> 5.232722386466869E10 cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9
> memory}, id = 142292
> 01-03Project(TotalSpend=[$0]) : rowType = RecordType(ANY
> TotalSpend): rowcount = 2.87997024E8, cumulative cost = {3.167967264E9 rows,
> 4.734841414759049E10 cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9
> memory}, id = 142291
> 01-04 HashToRandomExchange(dist0=[[$0]]) : rowType =
> RecordType(ANY TotalSpend, ANY E_X_P_R_H_A_S_H_F_I_E_L_D): rowcount =
> 2.87997024E8, cumulative cost = {3.167967264E9 rows, 4.734841414759049E10
> cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9 memory}, id = 142290
> 02-01UnorderedMuxExchange : rowType = RecordType(ANY
> TotalSpend, ANY E_X_P_R_H_A_S_H_F_I_E_L_D): rowcount = 2.87997024E8,
> cumulative cost = {2.87997024E9 rows, 4.274046176359049E10 cpu, 0.0 io,
> 3.538907430912E12 network, 4.607952384E9 memory}, id = 142289
> 03-01 Project(TotalSpend=[$0],
> E_X_P_R_H_A_S_H_F_I_E_L_D=[castInt(hash64AsDouble($0))]) : rowType =
> RecordType(ANY TotalSpend, ANY E_X_P_R_H_A_S_H_F_I_E_L_D): rowcount =
> 2.87997024E8, cumulative cost = {2.591973216E9 rows, 4.245246473959049E10
> cpu, 0.0 io, 3.538907430912E12 network, 4.607952384E9 memory}, id = 142288
> 03-02Project(TotalSpend=[CASE(>($2, 0), CAST($3):ANY,
> null)]) : rowType = RecordType(ANY TotalSpend): rowcount = 2.87997024E8,
> cumulative cost = {2.303976192E9 rows, 4.130047664359049E10 cpu, 0.0 io,
> 3.538907430912E12 network, 4.607952384E9 memory}, id = 142287
> 03-03 Window(window#0=[window(partition {1} order by
> [] range between UNBOUNDED PRECEDING and UNBOUNDED FOLLOWING aggs [COUNT($0),
> $SUM0($0)])]) : rowType = RecordType(ANY ss_net_paid_
[jira] [Created] (DRILL-3307) Query with window function runs out of memory
Abhishek Girish created DRILL-3307:
--
Summary: Query with window function runs out of memory
Key: DRILL-3307
URL: https://issues.apache.org/jira/browse/DRILL-3307
Project: Apache Drill
Issue Type: Bug
Components: Query Planning & Optimization
Affects Versions: 1.1.0
Environment: Data set: TPC-DS SF 100 Parquet
Number of Nodes: 4
Reporter: Abhishek Girish
Assignee: Deneche A. Hakim
Attachments: drillbit.log.txt
Query with window function runs out of memory:
{code:sql}
SELECT SUM(ss.ss_net_paid_inc_tax) OVER (PARTITION BY ss.ss_store_sk) AS
TotalSpend FROM store_sales ss ORDER BY 1 LIMIT 20;
java.lang.RuntimeException: java.sql.SQLException: RESOURCE ERROR: One or more
nodes ran out of memory while executing the query.
Fragment 3:0
[Error Id: 9af19064-9175-46a4-b557-714d1c77cd76 on abhi6.qa.lab:31010]
at sqlline.IncrementalRows.hasNext(IncrementalRows.java:73)
at
sqlline.TableOutputFormat$ResizingRowsProvider.next(TableOutputFormat.java:85)
at sqlline.TableOutputFormat.print(TableOutputFormat.java:116)
at sqlline.SqlLine.print(SqlLine.java:1583)
at sqlline.Commands.execute(Commands.java:852)
at sqlline.Commands.sql(Commands.java:751)
at sqlline.SqlLine.dispatch(SqlLine.java:738)
at sqlline.SqlLine.begin(SqlLine.java:612)
at sqlline.SqlLine.start(SqlLine.java:366)
at sqlline.SqlLine.main(SqlLine.java:259)
{code}
Plan:
{code}
00-00Screen : rowType = RecordType(ANY TotalSpend): rowcount =
2.87997024E8, cumulative cost = {4.3487550824E9 rows, 5.7539970079068695E10
cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9 memory}, id = 142297
00-01 SelectionVectorRemover : rowType = RecordType(ANY TotalSpend):
rowcount = 2.87997024E8, cumulative cost = {4.31995538E9 rows,
5.751117037666869E10 cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9
memory}, id = 142296
00-02Limit(fetch=[20]) : rowType = RecordType(ANY TotalSpend): rowcount
= 2.87997024E8, cumulative cost = {4.031958356E9 rows, 5.722317335266869E10
cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9 memory}, id = 142295
00-03 SingleMergeExchange(sort0=[0 ASC]) : rowType = RecordType(ANY
TotalSpend): rowcount = 2.87997024E8, cumulative cost = {4.031958336E9 rows,
5.722317327266869E10 cpu, 0.0 io, 7.077814861824E12 network, 4.607952384E9
memory}, id = 142294
01-01SelectionVectorRemover : rowType = RecordType(ANY TotalSpend):
rowcount = 2.87997024E8, cumulative cost = {3.743961312E9 rows,
5.261522088866869E10 cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9
memory}, id = 142293
01-02 TopN(limit=[20]) : rowType = RecordType(ANY TotalSpend):
rowcount = 2.87997024E8, cumulative cost = {3.455964288E9 rows,
5.232722386466869E10 cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9
memory}, id = 142292
01-03Project(TotalSpend=[$0]) : rowType = RecordType(ANY
TotalSpend): rowcount = 2.87997024E8, cumulative cost = {3.167967264E9 rows,
4.734841414759049E10 cpu, 0.0 io, 5.89817905152E12 network, 4.607952384E9
memory}, id = 142291
01-04 HashToRandomExchange(dist0=[[$0]]) : rowType =
RecordType(ANY TotalSpend, ANY E_X_P_R_H_A_S_H_F_I_E_L_D): rowcount =
2.87997024E8, cumulative cost = {3.167967264E9 rows, 4.734841414759049E10 cpu,
0.0 io, 5.89817905152E12 network, 4.607952384E9 memory}, id = 142290
02-01UnorderedMuxExchange : rowType = RecordType(ANY
TotalSpend, ANY E_X_P_R_H_A_S_H_F_I_E_L_D): rowcount = 2.87997024E8, cumulative
cost = {2.87997024E9 rows, 4.274046176359049E10 cpu, 0.0 io, 3.538907430912E12
network, 4.607952384E9 memory}, id = 142289
03-01 Project(TotalSpend=[$0],
E_X_P_R_H_A_S_H_F_I_E_L_D=[castInt(hash64AsDouble($0))]) : rowType =
RecordType(ANY TotalSpend, ANY E_X_P_R_H_A_S_H_F_I_E_L_D): rowcount =
2.87997024E8, cumulative cost = {2.591973216E9 rows, 4.245246473959049E10 cpu,
0.0 io, 3.538907430912E12 network, 4.607952384E9 memory}, id = 142288
03-02Project(TotalSpend=[CASE(>($2, 0), CAST($3):ANY,
null)]) : rowType = RecordType(ANY TotalSpend): rowcount = 2.87997024E8,
cumulative cost = {2.303976192E9 rows, 4.130047664359049E10 cpu, 0.0 io,
3.538907430912E12 network, 4.607952384E9 memory}, id = 142287
03-03 Window(window#0=[window(partition {1} order by
[] range between UNBOUNDED PRECEDING and UNBOUNDED FOLLOWING aggs [COUNT($0),
$SUM0($0)])]) : rowType = RecordType(ANY ss_net_paid_inc_tax, ANY ss_store_sk,
BIGINT w0$o0, ANY w0$o1): rowcount = 2.87997024E8, cumulative cost =
{2.015979168E9 rows, 4.014848854759049E10 cpu, 0.0 io, 3.538907430912E12
network, 4.607952384E9 memory}, id = 142286
03-04SelectionVectorRemover : rowType =
RecordType(ANY ss_net_paid_inc_tax,
[jira] [Commented] (DRILL-3306) Concurrently Running hive queries results in a deadlock situation
[
https://issues.apache.org/jira/browse/DRILL-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590835#comment-14590835
]
Rahul Challapalli commented on DRILL-3306:
--
Will Do! Thanks Jason
> Concurrently Running hive queries results in a deadlock situation
> -
>
> Key: DRILL-3306
> URL: https://issues.apache.org/jira/browse/DRILL-3306
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Hive
>Reporter: Rahul Challapalli
>Assignee: Venki Korukanti
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: error.log
>
>
> I tried submitting ~20 queries using 10 concurrent threads. Now the drillbit
> goes into an unresponsive state. Now even trying to launch a new sqlline
> session hangs (until hive.metastore.client.socket.timeout expires)
> Below is the jstack output
> {code}
> Attaching to process ID 4662, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 24.65-b04
> Deadlock Detection:
> java.lang.RuntimeException: Unable to deduce type of thread from address
> 0x7fc0f863 (expected type JavaThread, CompilerThread, ServiceThread,
> JvmtiAgentThread, or SurrogateLockerThread)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
> at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.createThreadTable(DeadlockDetector.java:149)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:56)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
> at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
> at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
> at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
> at sun.tools.jstack.JStack.main(JStack.java:102)
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for
> type of address 0x7fc0f863
> at
> sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at
> sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:158)
> ... 15 more
> Can't print deadlocks:Unable to deduce type of thread from address
> 0x7fc0f863 (expected type JavaThread, CompilerThread, ServiceThread,
> JvmtiAgentThread, or SurrogateLockerThread)
> Exception in thread "main" java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
> at sun.tools.jstack.JStack.main(JStack.java:102)
> Caused by: java.lang.RuntimeException: Unable to deduce type of thread from
> address 0x7fc0f863 (expected type JavaThread, CompilerThread,
> ServiceThread, JvmtiAgentThread, or SurrogateLockerThread)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
> at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:65)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
> at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
> at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
> at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
> ... 6 more
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for
> type of address 0x7fc0f863
> at
> sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at
> sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:158)
> ... 12 more
> {code}
> Jstack Output of the hive metastore
> {code}
> Attaching to process
[jira] [Commented] (DRILL-3306) Concurrently Running hive queries results in a deadlock situation
[
https://issues.apache.org/jira/browse/DRILL-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590834#comment-14590834
]
Jason Altekruse commented on DRILL-3306:
[~rkins] Please remember to set the fix version, we should be checking priority
of all bugs, but as we get close to a release we might be filtering on issues
just tagged for this release. We definitely should be looking at this before
1.1 is wrapped up.
> Concurrently Running hive queries results in a deadlock situation
> -
>
> Key: DRILL-3306
> URL: https://issues.apache.org/jira/browse/DRILL-3306
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Hive
>Reporter: Rahul Challapalli
>Assignee: Venki Korukanti
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: error.log
>
>
> I tried submitting ~20 queries using 10 concurrent threads. Now the drillbit
> goes into an unresponsive state. Now even trying to launch a new sqlline
> session hangs (until hive.metastore.client.socket.timeout expires)
> Below is the jstack output
> {code}
> Attaching to process ID 4662, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 24.65-b04
> Deadlock Detection:
> java.lang.RuntimeException: Unable to deduce type of thread from address
> 0x7fc0f863 (expected type JavaThread, CompilerThread, ServiceThread,
> JvmtiAgentThread, or SurrogateLockerThread)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
> at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.createThreadTable(DeadlockDetector.java:149)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:56)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
> at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
> at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
> at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
> at sun.tools.jstack.JStack.main(JStack.java:102)
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for
> type of address 0x7fc0f863
> at
> sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at
> sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:158)
> ... 15 more
> Can't print deadlocks:Unable to deduce type of thread from address
> 0x7fc0f863 (expected type JavaThread, CompilerThread, ServiceThread,
> JvmtiAgentThread, or SurrogateLockerThread)
> Exception in thread "main" java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
> at sun.tools.jstack.JStack.main(JStack.java:102)
> Caused by: java.lang.RuntimeException: Unable to deduce type of thread from
> address 0x7fc0f863 (expected type JavaThread, CompilerThread,
> ServiceThread, JvmtiAgentThread, or SurrogateLockerThread)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
> at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:65)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
> at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
> at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
> at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
> ... 6 more
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for
> type of address 0x7fc0f863
> at
> sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at
> sun.jvm.hotspot.runtime.VirtualConstructor.instan
[jira] [Updated] (DRILL-3306) Concurrently Running hive queries results in a deadlock situation
[
https://issues.apache.org/jira/browse/DRILL-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Altekruse updated DRILL-3306:
---
Fix Version/s: 1.1.0
> Concurrently Running hive queries results in a deadlock situation
> -
>
> Key: DRILL-3306
> URL: https://issues.apache.org/jira/browse/DRILL-3306
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Hive
>Reporter: Rahul Challapalli
>Assignee: Venki Korukanti
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: error.log
>
>
> I tried submitting ~20 queries using 10 concurrent threads. Now the drillbit
> goes into an unresponsive state. Now even trying to launch a new sqlline
> session hangs (until hive.metastore.client.socket.timeout expires)
> Below is the jstack output
> {code}
> Attaching to process ID 4662, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 24.65-b04
> Deadlock Detection:
> java.lang.RuntimeException: Unable to deduce type of thread from address
> 0x7fc0f863 (expected type JavaThread, CompilerThread, ServiceThread,
> JvmtiAgentThread, or SurrogateLockerThread)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
> at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.createThreadTable(DeadlockDetector.java:149)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:56)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
> at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
> at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
> at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
> at sun.tools.jstack.JStack.main(JStack.java:102)
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for
> type of address 0x7fc0f863
> at
> sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at
> sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:158)
> ... 15 more
> Can't print deadlocks:Unable to deduce type of thread from address
> 0x7fc0f863 (expected type JavaThread, CompilerThread, ServiceThread,
> JvmtiAgentThread, or SurrogateLockerThread)
> Exception in thread "main" java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
> at sun.tools.jstack.JStack.main(JStack.java:102)
> Caused by: java.lang.RuntimeException: Unable to deduce type of thread from
> address 0x7fc0f863 (expected type JavaThread, CompilerThread,
> ServiceThread, JvmtiAgentThread, or SurrogateLockerThread)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
> at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:65)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
> at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
> at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
> at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
> ... 6 more
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for
> type of address 0x7fc0f863
> at
> sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at
> sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:158)
> ... 12 more
> {code}
> Jstack Output of the hive metastore
> {code}
> Attaching to process ID 32320, please wait...
> Debugger attached successfully.
[jira] [Updated] (DRILL-669) Information Schema should be schema sensitive
[ https://issues.apache.org/jira/browse/DRILL-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-669: Assignee: Venki Korukanti (was: Mehant Baid) > Information Schema should be schema sensitive > - > > Key: DRILL-669 > URL: https://issues.apache.org/jira/browse/DRILL-669 > Project: Apache Drill > Issue Type: Bug > Components: Storage - Hive >Reporter: Rahul Challapalli >Assignee: Venki Korukanti >Priority: Minor > Fix For: 1.1.0 > > > If I am currently using the 'hive' schema/database, then information schema > should only contain information relevant to 'hive' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2522) Implement INFORMATION_SCHEMA.* enough for relevant tools [bug]
[
https://issues.apache.org/jira/browse/DRILL-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2522:
--
Description:
Note: This JIRA report is/was intended in part for for tracking specific
noticed differences between Drill and standard SQL (not necessarily differences
we've already decided to fix), and also in part as a reminder of this
likelihood of running into problems with tools that we care about (even that
set of problems isn't known now).
Drill's {{INFORMATION_SCHEMA.COLUMNS}} is not fully compliant with SQL:2011.
See DRILL-2763 regarding
{{INFORMATION_SCHEMA.COLUMNS}} (as opposed to other {{INFORMATION_SCHEMA.}}_*_
tables/views ).
Notes (to be edited/triaged/etc):
- {{INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME}} does not exist.
- Short-name views of existing tables (e.g., {{TABLES_S}} for {{TABLES}}) do
not exist.
- (Most standard-specified tables/views do not exist, but many probably aren't
relevant for Drill.)
was:
See DRILL-2763 regarding
{{INFORMATION_SCHEMA.COLUMNS}} (as opposed to other {{INFORMATION_SCHEMA.}}_*_
tables/views ).
Notes (to be edited/triaged/etc):
- {{INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME}} does not exist.
- Short-name views of existing tables (e.g., {{TABLES_S}} for {{TABLES}}) do
not exist.
- (Most standard-specified tables/views do not exist, but many probably aren't
relevant for Drill.)
> Implement INFORMATION_SCHEMA.* enough for relevant tools [bug]
> --
>
> Key: DRILL-2522
> URL: https://issues.apache.org/jira/browse/DRILL-2522
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Information Schema
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: 1.2.0
>
>
> Note: This JIRA report is/was intended in part for for tracking specific
> noticed differences between Drill and standard SQL (not necessarily
> differences we've already decided to fix), and also in part as a reminder of
> this likelihood of running into problems with tools that we care about (even
> that set of problems isn't known now).
> Drill's {{INFORMATION_SCHEMA.COLUMNS}} is not fully compliant with SQL:2011.
> See DRILL-2763 regarding
> {{INFORMATION_SCHEMA.COLUMNS}} (as opposed to other
> {{INFORMATION_SCHEMA.}}_*_ tables/views ).
> Notes (to be edited/triaged/etc):
> - {{INFORMATION_SCHEMA.INFORMATION_SCHEMA_CATALOG_NAME}} does not exist.
> - Short-name views of existing tables (e.g., {{TABLES_S}} for {{TABLES}}) do
> not exist.
> - (Most standard-specified tables/views do not exist, but many probably
> aren't relevant for Drill.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2763) [umbrella] Implement INFORMATION_SCHEMA.COLUMNS enough for relevant tools
[
https://issues.apache.org/jira/browse/DRILL-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2763:
--
Description:
\[Edit: Problems marked with "\[3216]" were fixed by DRILL-3216.]
Note: This JIRA report is/was intended in part for for tracking specific
noticed differences between Drill and standard SQL (not necessarily differences
we've already decided to fix), and also in part as a reminder of this
likelihood of running into problems with tools that we care about (even that
set of problems isn't known now).
Drill's {{INFORMATION_SCHEMA.COLUMNS}} is not compliant with SQL:2011.
*A. {{COLUMNS}} columns existing in Drill that are not compliant with standard
SQL*:
1. *TDB*: {{TABLE_NAME}} holds the original form of the identifier but _might_
need to be uppercased here to be compliant (or possibly internal matching
queries (e.g., for JDBC's getColumns(...)) could be case-insensitive).
2. *TDB*: {{COLUMN_NAME}} holds the original form of the identifier but _might_
need to be uppercased here to be compliant (or possibly internal matching
queries (e.g., for JDBC's getColumns(...)) could be case-insensitive).
3. \[3216] {{ORDINAL_POSITION}} values are zero-based rather than being
one-based.
4. \[3216] {{CHARACTER_MAXIMUM_LENGTH}}, {{NUMERIC_PRECISION_RADIX}},
{{NUMERIC_SCALE}}, and {{NUMERIC_PRECISION}} use {{-1}} instead of {{NULL}} for
the "not-applicable" case.
5. \[3216] {{NUMERIC_PRECISION}} for non-{{DECIMAL}}/{{NUMERIC}} exact numeric
types (e.g., {{INTEGER}}) and approximate numeric types (e.g., {{DOUBLE}}) is
{{-1}} (logical null) instead of the specified values.
6. \[3216] {{NUMERIC_SCALE}} for non-{{DECIMAL}}/{{NUMERIC}} exact numeric
types is {{-1}} instead of {{0}}.
7. \[3216] {{NUMERIC_SCALE}} for approximate numeric types is {{-1}} instead of
the number of bits of precision (24 and 53(?)).
8. \[3216] {{NUMERIC_PRECISION_RADIX}} for integral exact numeric types is
{{-1}} instead of {{10}}.
9. \[3216] {{NUMERIC_PRECISION_RADIX}} for approximate exact numeric types is
{{-1}} instead of {{2}}.
10. \[3216] {{CHARACTER_MAXIMUM_LENGTH}} for types {{CHAR}}, {{BINARY}}, and
{{VAR BINARY}} is {{-1}} instead of the corresponding length.
11. \[3216] {{DATA_TYPE}} values for {{INTERVAL}} with {{YEAR}} and/or
{{MONTH}} and for {{INTERVAL}} with {{DAY}}, {{HOUR}}, {{MINUTE}}, and/or
{{SECOND}} are "{{INTERVAL_YEAR_MONTH}}" and "{{INTERVAL_DATA_TIME}}",
respectively, instead of the data type name "{{INTERVAL}}".
12. \[3216] {{DATA_TYPE}} values for non-atomic types seem to be type
descriptors ({{}} syntax; e.g., "{{VARCHAR(65536) ARRAY}}") instead
of just data type names (e.g., "{{ARRAY}}").
*B. Standard {{COLUMNS}} columns that don't exist in Drill and that probably
are more relevant*:
1. \[3216] {{CHARACTER_OCTET_LENGTH}} does not exist. (Drill's JDBC driver
needs to return this, and currently tries to compute it itself.)
2. \[3216] {{DATETIME_PRECISION}} does not exist. (Drill's JDBC driver probably
needs it to compute its {{getColumns()}}'s {{COLUMN_SIZE}} correctly.)
3. \[3216] {{INTERVAL_TYPE}} does not exist. (Drill's JDBC driver needs this to
compute its {{getColumns()}}'s {{COLUMN_SIZE}} correctly once
{{COLUMNS.DATA_TYPE}} is correct.}
4. \[3216] {{INTERVAL_PRECISION}} does not exist. (Drill's JDBC driver needs
this to compute its {{getColumns()}}'s {{COLUMN_SIZE}} correctly.)
\[TBD]:
5. {{MAXIMUM_CARDINALITY}} does not exist. (This might be relevant for JDBC's
{{getColumns()}}'s {{COLUMN_SIZE}}.)
*C. Standard {{COLUMNS}} columns that don't exist in Drill but are less likely
to be relevant (listed for completeness)*:
- \[3216] {{COLUMN_DEFAULT}}
- {{CHARACTER_SET_CATALOG}}
- {{CHARACTER_SET_SCHEMA}}
- {{CHARACTER_SET_NAME}}
- {{COLLATION_CATALOG}}
- {{COLLATION_SCHEMA}}
- {{COLLATION_NAME}}
- {{DOMAIN_CATALOG}}
- {{DOMAIN_SCHEMA}}
- {{DOMAIN_NAME}}
- {{UDT_CATALOG}}
- {{UDT_SCHEMA}}
- {{UDT_NAME}}
- {{SCOPE_CATALOG}}
- {{SCOPE_SCHEMA}}
- {{SCOPE_NAME}}
- {{DTD_IDENTIFIER}}
- {{IS_SELF_REFERENCING}}
- {{IS_IDENTITY}}
- {{IDENTITY_GENERATION}}
- {{IDENTITY_START}}
- {{IDENTITY_INCREMENT}}
- {{IDENTITY_MAXIMUM}}
- {{IDENTITY_MINIMUM}}
- {{IDENTITY_CYCLE}}
- {{IS_GENERATED}}
- {{GENERATION_EXPRESSION}}
- {{IS_SYSTEM_TIME_PERIOD_START}}
- {{IS_SYSTEM_TIME_PERIOD_END}}
- {{SYSTEM_TIME_PERIOD_TIMESTAMP_GENERATION}}
- {{IS_UPDATABLE}}
- {{DECLARED_DATA_TYPE}}
- {{DECLARED_NUMERIC_PRECISION}}
- {{DECLARED_NUMERIC_SCALE}}
was:
\[Edit: Problems marked with "\[3216]" were fixed by DRILL-3216.]
This JIRA report is/was intended for tracking known
Drill's {{INFORMATION_SCHEMA.COLUMNS}} isn't compliant with SQL:2011.
*A. {{COLUMNS}} columns existing in Drill that are not compliant with standard
SQL*:
1. *TDB*: {{TABLE_NAME}} holds the original form of the identifier but _might_
need to be uppercased here to be compliant (or possibly internal matc
[jira] [Updated] (DRILL-1673) Flatten function can not work well with nested arrays.
[
https://issues.apache.org/jira/browse/DRILL-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Parth Chandra updated DRILL-1673:
-
Assignee: Mehant Baid (was: Jason Altekruse)
> Flatten function can not work well with nested arrays.
> --
>
> Key: DRILL-1673
> URL: https://issues.apache.org/jira/browse/DRILL-1673
> Project: Apache Drill
> Issue Type: Bug
> Components: Functions - Drill
>Affects Versions: 0.7.0
> Environment: 0.7.0
>Reporter: Hao Zhu
>Assignee: Mehant Baid
>Priority: Blocker
> Fix For: 1.1.0
>
> Attachments: DRILL-1673.patch, error.log
>
>
> Flatten function failed to scan nested arrays , for example something like
> ""[[ ]]"".
> The only difference of JSON files between below 2 tests is
> "num":[1,2,3]
> VS
> "num":[[1,2,3]]
> ==Test 1 (Works well):==
> file:
> {code}
> {"fixed_column":"abc", "list_column":[{"id1":"1","name":"zhu", "num":
> [1,2,3]}, {"id1":"2","name":"hao", "num": [4,5,6]} ]}
> {code}
> SQL:
> {code}
> 0: jdbc:drill:zk=local> select t.`fixed_column` as fixed_column,
> flatten(t.`list_column`) from
> dfs.root.`/Users/hzu/Documents/sharefolder/hp/n2.json` as t;
> +--++
> | fixed_column | EXPR$1 |
> +--++
> | abc | {"id1":"1","name":"zhu","num":[1,2,3]} |
> | abc | {"id1":"2","name":"hao","num":[4,5,6]} |
> +--++
> 2 rows selected (0.154 seconds)
> {code}
> ==Test 2 (Failed):==
> file:
> {code}
> {"fixed_column":"abc", "list_column":[{"id1":"1","name":"zhu", "num":
> [[1,2,3]]}, {"id1":"2","name":"hao", "num": [[4,5,6]]} ]}
> {code}
> SQL:
> {code}
> 0: jdbc:drill:zk=local> select t.`fixed_column` as fixed_column,
> flatten(t.`list_column`) from
> dfs.root.`/Users/hzu/Documents/sharefolder/hp/n3.json` as t;
> +--++
> | fixed_column | EXPR$1 |
> +--++
> Query failed: Failure while running fragment.[
> df28347b-fac1-497d-b9c5-a313ba77aa4d on 10.250.0.115:31010 ]
> (java.lang.UnsupportedOperationException)
>
> org.apache.drill.exec.vector.complex.RepeatedListVector$RepeatedListTransferPair.splitAndTransfer():339
>
> org.apache.drill.exec.vector.complex.RepeatedMapVector$SingleMapTransferPair.splitAndTransfer():305
> org.apache.drill.exec.test.generated.FlattenerGen22.flattenRecords():93
>
> org.apache.drill.exec.physical.impl.flatten.FlattenRecordBatch.doWork():152
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext():89
>
> org.apache.drill.exec.physical.impl.flatten.FlattenRecordBatch.innerNext():118
> org.apache.drill.exec.record.AbstractRecordBatch.next():106
>
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next():124
> org.apache.drill.exec.record.AbstractRecordBatch.next():86
> org.apache.drill.exec.record.AbstractRecordBatch.next():76
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext():52
>
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext():129
> org.apache.drill.exec.record.AbstractRecordBatch.next():106
>
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next():124
> org.apache.drill.exec.physical.impl.BaseRootExec.next():67
>
> org.apache.drill.exec.physical.impl.ScreenCreator$ScreenRoot.innerNext():122
> org.apache.drill.exec.physical.impl.BaseRootExec.next():57
> org.apache.drill.exec.work.fragment.FragmentExecutor.run():105
> org.apache.drill.exec.work.WorkManager$RunnableWrapper.run():249
> ...():0
> java.lang.RuntimeException: java.sql.SQLException: Failure while executing
> query.
> at sqlline.SqlLine$IncrementalRows.hasNext(SqlLine.java:2514)
> at sqlline.SqlLine$TableOutputFormat.print(SqlLine.java:2148)
> at sqlline.SqlLine.print(SqlLine.java:1809)
> at sqlline.SqlLine$Commands.execute(SqlLine.java:3766)
> at sqlline.SqlLine$Commands.sql(SqlLine.java:3663)
> at sqlline.SqlLine.dispatch(SqlLine.java:889)
> at sqlline.SqlLine.begin(SqlLine.java:763)
> at sqlline.SqlLine.start(SqlLine.java:498)
> at sqlline.SqlLine.main(SqlLine.java:460)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-3306) Concurrently Running hive queries results in a deadlock situation
[
https://issues.apache.org/jira/browse/DRILL-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590793#comment-14590793
]
Rahul Challapalli commented on DRILL-3306:
--
I tried reproducing the issue with submitting 2 queries with 2 threads. Now one
query finished immediately and second query took 10+ minutes to complete. I
have seen the same query fail after 10 mins with table not found error as well.
> Concurrently Running hive queries results in a deadlock situation
> -
>
> Key: DRILL-3306
> URL: https://issues.apache.org/jira/browse/DRILL-3306
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Hive
>Reporter: Rahul Challapalli
>Assignee: Venki Korukanti
>Priority: Critical
> Attachments: error.log
>
>
> I tried submitting ~20 queries using 10 concurrent threads. Now the drillbit
> goes into an unresponsive state. Now even trying to launch a new sqlline
> session hangs (until hive.metastore.client.socket.timeout expires)
> Below is the jstack output
> {code}
> Attaching to process ID 4662, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 24.65-b04
> Deadlock Detection:
> java.lang.RuntimeException: Unable to deduce type of thread from address
> 0x7fc0f863 (expected type JavaThread, CompilerThread, ServiceThread,
> JvmtiAgentThread, or SurrogateLockerThread)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
> at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.createThreadTable(DeadlockDetector.java:149)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:56)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
> at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
> at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
> at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
> at sun.tools.jstack.JStack.main(JStack.java:102)
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for
> type of address 0x7fc0f863
> at
> sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at
> sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:158)
> ... 15 more
> Can't print deadlocks:Unable to deduce type of thread from address
> 0x7fc0f863 (expected type JavaThread, CompilerThread, ServiceThread,
> JvmtiAgentThread, or SurrogateLockerThread)
> Exception in thread "main" java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
> at sun.tools.jstack.JStack.main(JStack.java:102)
> Caused by: java.lang.RuntimeException: Unable to deduce type of thread from
> address 0x7fc0f863 (expected type JavaThread, CompilerThread,
> ServiceThread, JvmtiAgentThread, or SurrogateLockerThread)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
> at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:65)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
> at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
> at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
> at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
> ... 6 more
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for
> type of address 0x7fc0f863
> at
> sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at
> sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
>
[jira] [Updated] (DRILL-2763) [umbrella] Implement INFORMATION_SCHEMA.COLUMNS enough for relevant tools
[
https://issues.apache.org/jira/browse/DRILL-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2763:
--
Description:
\[Edit: Problems marked with "\[3216]" were fixed by DRILL-3216.]
This JIRA report is/was intended for tracking known
Drill's {{INFORMATION_SCHEMA.COLUMNS}} isn't compliant with SQL:2011.
*A. {{COLUMNS}} columns existing in Drill that are not compliant with standard
SQL*:
1. *TDB*: {{TABLE_NAME}} holds the original form of the identifier but _might_
need to be uppercased here to be compliant (or possibly internal matching
queries (e.g., for JDBC's getColumns(...)) could be case-insensitive).
2. *TDB*: {{COLUMN_NAME}} holds the original form of the identifier but _might_
need to be uppercased here to be compliant (or possibly internal matching
queries (e.g., for JDBC's getColumns(...)) could be case-insensitive).
3. \[3216] {{ORDINAL_POSITION}} values are zero-based rather than being
one-based.
4. \[3216] {{CHARACTER_MAXIMUM_LENGTH}}, {{NUMERIC_PRECISION_RADIX}},
{{NUMERIC_SCALE}}, and {{NUMERIC_PRECISION}} use {{-1}} instead of {{NULL}} for
the "not-applicable" case.
5. \[3216] {{NUMERIC_PRECISION}} for non-{{DECIMAL}}/{{NUMERIC}} exact numeric
types (e.g., {{INTEGER}}) and approximate numeric types (e.g., {{DOUBLE}}) is
{{-1}} (logical null) instead of the specified values.
6. \[3216] {{NUMERIC_SCALE}} for non-{{DECIMAL}}/{{NUMERIC}} exact numeric
types is {{-1}} instead of {{0}}.
7. \[3216] {{NUMERIC_SCALE}} for approximate numeric types is {{-1}} instead of
the number of bits of precision (24 and 53(?)).
8. \[3216] {{NUMERIC_PRECISION_RADIX}} for integral exact numeric types is
{{-1}} instead of {{10}}.
9. \[3216] {{NUMERIC_PRECISION_RADIX}} for approximate exact numeric types is
{{-1}} instead of {{2}}.
10. \[3216] {{CHARACTER_MAXIMUM_LENGTH}} for types {{CHAR}}, {{BINARY}}, and
{{VAR BINARY}} is {{-1}} instead of the corresponding length.
11. \[3216] {{DATA_TYPE}} values for {{INTERVAL}} with {{YEAR}} and/or
{{MONTH}} and for {{INTERVAL}} with {{DAY}}, {{HOUR}}, {{MINUTE}}, and/or
{{SECOND}} are "{{INTERVAL_YEAR_MONTH}}" and "{{INTERVAL_DATA_TIME}}",
respectively, instead of the data type name "{{INTERVAL}}".
12. \[3216] {{DATA_TYPE}} values for non-atomic types seem to be type
descriptors ({{}} syntax; e.g., "{{VARCHAR(65536) ARRAY}}") instead
of just data type names (e.g., "{{ARRAY}}").
*B. Standard {{COLUMNS}} columns that don't exist in Drill and that probably
are more relevant*:
1. \[3216] {{CHARACTER_OCTET_LENGTH}} does not exist. (Drill's JDBC driver
needs to return this, and currently tries to compute it itself.)
2. \[3216] {{DATETIME_PRECISION}} does not exist. (Drill's JDBC driver probably
needs it to compute its {{getColumns()}}'s {{COLUMN_SIZE}} correctly.)
3. \[3216] {{INTERVAL_TYPE}} does not exist. (Drill's JDBC driver needs this to
compute its {{getColumns()}}'s {{COLUMN_SIZE}} correctly once
{{COLUMNS.DATA_TYPE}} is correct.}
4. \[3216] {{INTERVAL_PRECISION}} does not exist. (Drill's JDBC driver needs
this to compute its {{getColumns()}}'s {{COLUMN_SIZE}} correctly.)
\[TBD]:
5. {{MAXIMUM_CARDINALITY}} does not exist. (This might be relevant for JDBC's
{{getColumns()}}'s {{COLUMN_SIZE}}.)
*C. Standard {{COLUMNS}} columns that don't exist in Drill but are less likely
to be relevant (listed for completeness)*:
- \[3216] {{COLUMN_DEFAULT}}
- {{CHARACTER_SET_CATALOG}}
- {{CHARACTER_SET_SCHEMA}}
- {{CHARACTER_SET_NAME}}
- {{COLLATION_CATALOG}}
- {{COLLATION_SCHEMA}}
- {{COLLATION_NAME}}
- {{DOMAIN_CATALOG}}
- {{DOMAIN_SCHEMA}}
- {{DOMAIN_NAME}}
- {{UDT_CATALOG}}
- {{UDT_SCHEMA}}
- {{UDT_NAME}}
- {{SCOPE_CATALOG}}
- {{SCOPE_SCHEMA}}
- {{SCOPE_NAME}}
- {{DTD_IDENTIFIER}}
- {{IS_SELF_REFERENCING}}
- {{IS_IDENTITY}}
- {{IDENTITY_GENERATION}}
- {{IDENTITY_START}}
- {{IDENTITY_INCREMENT}}
- {{IDENTITY_MAXIMUM}}
- {{IDENTITY_MINIMUM}}
- {{IDENTITY_CYCLE}}
- {{IS_GENERATED}}
- {{GENERATION_EXPRESSION}}
- {{IS_SYSTEM_TIME_PERIOD_START}}
- {{IS_SYSTEM_TIME_PERIOD_END}}
- {{SYSTEM_TIME_PERIOD_TIMESTAMP_GENERATION}}
- {{IS_UPDATABLE}}
- {{DECLARED_DATA_TYPE}}
- {{DECLARED_NUMERIC_PRECISION}}
- {{DECLARED_NUMERIC_SCALE}}
was:
[TBD: intro.]
\[Edit: "\[3216]" marks problems fixed by DRILL-3216.]
*A. {{COLUMNS}} columns existing in Drill that are not compliant with standard
SQL*:
1. *TDB*: {{TABLE_NAME}} holds the original form of the identifier but _might_
need to be uppercased here to be compliant (or possibly internal matching
queries (e.g., for JDBC's getColumns(...)) could be case-insensitive).
2. *TDB*: {{COLUMN_NAME}} holds the original form of the identifier but _might_
need to be uppercased here to be compliant (or possibly internal matching
queries (e.g., for JDBC's getColumns(...)) could be case-insensitive).
3. \[3216] {{ORDINAL_POSITION}} values are zero-based rather than being
one-based.
4. \[3216] {{CHARACT
[jira] [Updated] (DRILL-2763) [umbrella] Implement INFORMATION_SCHEMA.COLUMNS enough for relevant tools
[
https://issues.apache.org/jira/browse/DRILL-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2763:
--
Description:
[TBD: intro.]
\[Edit: "\[3216]" marks problems fixed by DRILL-3216.]
*A. {{COLUMNS}} columns existing in Drill that are not compliant with standard
SQL*:
1. *TDB*: {{TABLE_NAME}} holds the original form of the identifier but _might_
need to be uppercased here to be compliant (or possibly internal matching
queries (e.g., for JDBC's getColumns(...)) could be case-insensitive).
2. *TDB*: {{COLUMN_NAME}} holds the original form of the identifier but _might_
need to be uppercased here to be compliant (or possibly internal matching
queries (e.g., for JDBC's getColumns(...)) could be case-insensitive).
3. \[3216] {{ORDINAL_POSITION}} values are zero-based rather than being
one-based.
4. \[3216] {{CHARACTER_MAXIMUM_LENGTH}}, {{NUMERIC_PRECISION_RADIX}},
{{NUMERIC_SCALE}}, and {{NUMERIC_PRECISION}} use {{-1}} instead of {{NULL}} for
the "not-applicable" case.
5. \[3216] {{NUMERIC_PRECISION}} for non-{{DECIMAL}}/{{NUMERIC}} exact numeric
types (e.g., {{INTEGER}}) and approximate numeric types (e.g., {{DOUBLE}}) is
{{-1}} (logical null) instead of the specified values.
6. \[3216] {{NUMERIC_SCALE}} for non-{{DECIMAL}}/{{NUMERIC}} exact numeric
types is {{-1}} instead of {{0}}.
7. \[3216] {{NUMERIC_SCALE}} for approximate numeric types is {{-1}} instead of
the number of bits of precision (24 and 53(?)).
8. \[3216] {{NUMERIC_PRECISION_RADIX}} for integral exact numeric types is
{{-1}} instead of {{10}}.
9. \[3216] {{NUMERIC_PRECISION_RADIX}} for approximate exact numeric types is
{{-1}} instead of {{2}}.
10. \[3216] {{CHARACTER_MAXIMUM_LENGTH}} for types {{CHAR}}, {{BINARY}}, and
{{VAR BINARY}} is {{-1}} instead of the corresponding length.
11. \[3216] {{DATA_TYPE}} values for {{INTERVAL}} with {{YEAR}} and/or
{{MONTH}} and for {{INTERVAL}} with {{DAY}}, {{HOUR}}, {{MINUTE}}, and/or
{{SECOND}} are "{{INTERVAL_YEAR_MONTH}}" and "{{INTERVAL_DATA_TIME}}",
respectively, instead of the data type name "{{INTERVAL}}".
12. \[3216] {{DATA_TYPE}} values for non-atomic types seem to be type
descriptors ({{}} syntax; e.g., "{{VARCHAR(65536) ARRAY}}") instead
of just data type names (e.g., "{{ARRAY}}").
*B. Standard {{COLUMNS}} columns that don't exist in Drill and that probably
are more relevant*:
1. \[3216] {{CHARACTER_OCTET_LENGTH}} does not exist. (Drill's JDBC driver
needs to return this, and currently tries to compute it itself.)
2. \[3216] {{DATETIME_PRECISION}} does not exist. (Drill's JDBC driver probably
needs it to compute its {{getColumns()}}'s {{COLUMN_SIZE}} correctly.)
3. \[3216] {{INTERVAL_TYPE}} does not exist. (Drill's JDBC driver needs this to
compute its {{getColumns()}}'s {{COLUMN_SIZE}} correctly once
{{COLUMNS.DATA_TYPE}} is correct.}
4. \[3216] {{INTERVAL_PRECISION}} does not exist. (Drill's JDBC driver needs
this to compute its {{getColumns()}}'s {{COLUMN_SIZE}} correctly.)
\[TBD]:
5. {{MAXIMUM_CARDINALITY}} does not exist. (This might be relevant for JDBC's
{{getColumns()}}'s {{COLUMN_SIZE}}.)
*C. Standard {{COLUMNS}} columns that don't exist in Drill but are less likely
to be relevant (listed for completeness)*:
- \[3216] {{COLUMN_DEFAULT}}
- {{CHARACTER_SET_CATALOG}}
- {{CHARACTER_SET_SCHEMA}}
- {{CHARACTER_SET_NAME}}
- {{COLLATION_CATALOG}}
- {{COLLATION_SCHEMA}}
- {{COLLATION_NAME}}
- {{DOMAIN_CATALOG}}
- {{DOMAIN_SCHEMA}}
- {{DOMAIN_NAME}}
- {{UDT_CATALOG}}
- {{UDT_SCHEMA}}
- {{UDT_NAME}}
- {{SCOPE_CATALOG}}
- {{SCOPE_SCHEMA}}
- {{SCOPE_NAME}}
- {{DTD_IDENTIFIER}}
- {{IS_SELF_REFERENCING}}
- {{IS_IDENTITY}}
- {{IDENTITY_GENERATION}}
- {{IDENTITY_START}}
- {{IDENTITY_INCREMENT}}
- {{IDENTITY_MAXIMUM}}
- {{IDENTITY_MINIMUM}}
- {{IDENTITY_CYCLE}}
- {{IS_GENERATED}}
- {{GENERATION_EXPRESSION}}
- {{IS_SYSTEM_TIME_PERIOD_START}}
- {{IS_SYSTEM_TIME_PERIOD_END}}
- {{SYSTEM_TIME_PERIOD_TIMESTAMP_GENERATION}}
- {{IS_UPDATABLE}}
- {{DECLARED_DATA_TYPE}}
- {{DECLARED_NUMERIC_PRECISION}}
- {{DECLARED_NUMERIC_SCALE}}
was:
[TBD: intro.]
*A. {{COLUMNS}} columns existing in Drill that are not compliant with standard
SQL*:
1. *TDB*: {{TABLE_NAME}} holds the original form of the identifier but _might_
need to be uppercased here to be compliant (or possibly internal matching
queries (e.g., for JDBC's getColumns(...)) could be case-insensitive).
2. *TDB*: {{COLUMN_NAME}} holds the original form of the identifier but _might_
need to be uppercased here to be compliant (or possibly internal matching
queries (e.g., for JDBC's getColumns(...)) could be case-insensitive).
3. \[3216] {{ORDINAL_POSITION}} values are zero-based rather than being
one-based.
4. \[3216] {{CHARACTER_MAXIMUM_LENGTH}}, {{NUMERIC_PRECISION_RADIX}},
{{NUMERIC_SCALE}}, and {{NUMERIC_PRECISION}} use {{-1}} instead of {{NULL}} for
the "not-applicable" case.
5. \[3216] {{NUME
[jira] [Updated] (DRILL-3306) Concurrently Running hive queries results in a deadlock situation
[
https://issues.apache.org/jira/browse/DRILL-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Challapalli updated DRILL-3306:
-
Attachment: error.log
> Concurrently Running hive queries results in a deadlock situation
> -
>
> Key: DRILL-3306
> URL: https://issues.apache.org/jira/browse/DRILL-3306
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Hive
>Reporter: Rahul Challapalli
>Assignee: Venki Korukanti
>Priority: Critical
> Attachments: error.log
>
>
> I tried submitting ~20 queries using 10 concurrent threads. Now the drillbit
> goes into an unresponsive state. Now even trying to launch a new sqlline
> session hangs (until hive.metastore.client.socket.timeout expires)
> Below is the jstack output
> {code}
> Attaching to process ID 4662, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 24.65-b04
> Deadlock Detection:
> java.lang.RuntimeException: Unable to deduce type of thread from address
> 0x7fc0f863 (expected type JavaThread, CompilerThread, ServiceThread,
> JvmtiAgentThread, or SurrogateLockerThread)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
> at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.createThreadTable(DeadlockDetector.java:149)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:56)
> at
> sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
> at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
> at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
> at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
> at sun.tools.jstack.JStack.main(JStack.java:102)
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for
> type of address 0x7fc0f863
> at
> sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at
> sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:158)
> ... 15 more
> Can't print deadlocks:Unable to deduce type of thread from address
> 0x7fc0f863 (expected type JavaThread, CompilerThread, ServiceThread,
> JvmtiAgentThread, or SurrogateLockerThread)
> Exception in thread "main" java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
> at sun.tools.jstack.JStack.main(JStack.java:102)
> Caused by: java.lang.RuntimeException: Unable to deduce type of thread from
> address 0x7fc0f863 (expected type JavaThread, CompilerThread,
> ServiceThread, JvmtiAgentThread, or SurrogateLockerThread)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
> at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:65)
> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
> at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
> at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
> at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
> ... 6 more
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for
> type of address 0x7fc0f863
> at
> sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at
> sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at
> sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:158)
> ... 12 more
> {code}
> Jstack Output of the hive metastore
> {code}
> Attaching to process ID 32320, please wait...
> Debugger attached successfully.
> Server compiler detected
[jira] [Created] (DRILL-3306) Concurrently Running hive queries results in a deadlock situation
Rahul Challapalli created DRILL-3306:
Summary: Concurrently Running hive queries results in a deadlock
situation
Key: DRILL-3306
URL: https://issues.apache.org/jira/browse/DRILL-3306
Project: Apache Drill
Issue Type: Bug
Components: Storage - Hive
Reporter: Rahul Challapalli
Assignee: Venki Korukanti
Priority: Critical
I tried submitting ~20 queries using 10 concurrent threads. Now the drillbit
goes into an unresponsive state. Now even trying to launch a new sqlline
session hangs (until hive.metastore.client.socket.timeout expires)
Below is the jstack output
{code}
Attaching to process ID 4662, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.65-b04
Deadlock Detection:
java.lang.RuntimeException: Unable to deduce type of thread from address
0x7fc0f863 (expected type JavaThread, CompilerThread, ServiceThread,
JvmtiAgentThread, or SurrogateLockerThread)
at
sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
at
sun.jvm.hotspot.runtime.DeadlockDetector.createThreadTable(DeadlockDetector.java:149)
at
sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:56)
at
sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
at sun.tools.jstack.JStack.main(JStack.java:102)
Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type
of address 0x7fc0f863
at
sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
at
sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
at
sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:158)
... 15 more
Can't print deadlocks:Unable to deduce type of thread from address
0x7fc0f863 (expected type JavaThread, CompilerThread, ServiceThread,
JvmtiAgentThread, or SurrogateLockerThread)
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
at sun.tools.jstack.JStack.main(JStack.java:102)
Caused by: java.lang.RuntimeException: Unable to deduce type of thread from
address 0x7fc0f863 (expected type JavaThread, CompilerThread,
ServiceThread, JvmtiAgentThread, or SurrogateLockerThread)
at
sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:65)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
... 6 more
Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type
of address 0x7fc0f863
at
sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
at
sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
at
sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:158)
... 12 more
{code}
Jstack Output of the hive metastore
{code}
Attaching to process ID 32320, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.65-b04
Deadlock Detection:
java.lang.RuntimeException: Unable to deduce type of thread from address
0x7f1abd191800 (expected type JavaThread, CompilerThread, ServiceThread,
JvmtiAgentThread, or SurrogateLockerThread)
at
sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
[jira] [Assigned] (DRILL-3216) Fix existing(+) INFORMATION_SCHEMA.COLUMNS columns
[
https://issues.apache.org/jira/browse/DRILL-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) reassigned DRILL-3216:
-
Assignee: Daniel Barclay (Drill) (was: Parth Chandra)
> Fix existing(+) INFORMATION_SCHEMA.COLUMNS columns
> --
>
> Key: DRILL-3216
> URL: https://issues.apache.org/jira/browse/DRILL-3216
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: 1.1.0
>
> Attachments: DRILL-3216.1Hygiene.4.patch.txt,
> DRILL-3216.1Hygiene.6.patch.txt, DRILL-3216.1HygieneBASE.4.patch.txt,
> DRILL-3216.2Core.4.patch.txt, DRILL-3216.2Core.5.patch.txt,
> DRILL-3216.2Core.6.patch.txt, DRILL-3216.2CoreBASE.4.patch.txt
>
>
> Change logical null from {{-1}} to actual {{NULL}}:
> - Change column {{CHARACTER_MAXIMUM_LENGTH}}.
> - Change column {{NUMERIC_PRECISION}}.
> - Change column {{NUMERIC_PRECISION_RADIX}}.
> - Change column {{NUMERIC_SCALE}}.
> Change column {{ORDINAL_POSITION}} from zero-based to one-based.
> Change column {{DATA_TYPE}} from short names (e.g., "CHAR") to specified
> names (e.g., "CHARACTER").
> - "CHAR" -> "CHARACTER"
> - "VARCHAR" -> "CHARACTER VARYING"
> - "VARBINARY" -> "BINARY VARYING"
> - "... ARRAY" -> "ARRAY"
> - "STRUCT (...)" -> "STRUCT"
> - ("(...) MAP" -> "MAP" (extension to standard, but follows standard's
> pattern))
> Fix data type names "INTERVAL_DAY_TIME" and "INTERVAL_YEAR_MONTH" to
> "INTERVAL":
> - Change column {{DATA_TYPE}} to list "INTERVAL" for interval types.
> - Add column {{INTERVAL_TYPE}}.
> Move {{CHAR}} length from {{NUMERIC_PRECISION}} to
> {{CHARACTER_MAXIMUM_LENGTH}} (same as {{VARCHAR}} length):
> - Change column {{NUMERIC_PRECISION}} from length to logical null for CHAR.
> - Change column {{CHARACTER_MAXIMUM_LENGTH}} from logical null to length for
> CHAR.
> Move {{BINARY}} and {{VARBINARY}} length from {{NUMERIC_PRECISION}} to
> {{CHARACTER_MAXIMUM_LENGTH}} (same as CHAR and VARCHAR length):
> - Change column {{NUMERIC_PRECISION}} from length to logical null for BINARY
> and VARBINARY.
> - Change column {{CHARACTER_MAXIMUM_LENGTH}} from logical null to length for
> BINARY and VARBINARY.
> To correct ordinal position of some existing columns:
> - Add column {{COLUMN_DEFAULT}}.
> - Add column {{CHARACTER_OCTET_LENGTH}}.
> - Reorder column {{NUMERIC_PRECISION}}.
> Move date/time and interval precisions from {{NUMERIC_PRECISION}} to
> {{DATETIME_PRECISION}} and {{INTERVAL_PRECISION}}:
> - Change column {{NUMERIC_PRECISION}} to logically null for date/time and
> interval types.
> - Add column {{DATETIME_PRECISION}}.
> - Add column {{INTERVAL_PRECISION}}.
> Implement {{NUMERIC_PRECISION_RADIX}}:
> - Change column {{NUMERIC_PRECISION_RADIX}} from always logically null to
> appropriate values (2, 10, NULL).
> Add missing numeric precision and scale values (for non-DECIMAL types):
> - Change NUMERIC_SCALE from logical null to zero for integer types.
> - Change NUMERIC_PRECISION from logical null to precision for non-DECIMAL
> numeric types.
> Update implementation of JDBC's {{DatabaseMeta.getColumns()}}:
> - first, enough to not break
> - second, to use newly available data to fix some partial implementations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (DRILL-3198) JDBC driver returns null from DatabaseMetaData.getTypeInfo(...)
[ https://issues.apache.org/jira/browse/DRILL-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) reassigned DRILL-3198: - Assignee: Daniel Barclay (Drill) (was: Parth Chandra) > JDBC driver returns null from DatabaseMetaData.getTypeInfo(...) > --- > > Key: DRILL-3198 > URL: https://issues.apache.org/jira/browse/DRILL-3198 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Affects Versions: 1.0.0 >Reporter: Matt Keranen >Assignee: Daniel Barclay (Drill) > Fix For: 1.1.0 > > Attachments: DRILL-3198.4.patch.txt, DRILL-3198.5.patch.txt, > DRILL-3198.BASE.4.patch.txt > > > JDBC driver returns null from DatabaseMetaData#getTypeInfo() instead of a > ResultSet, causing some client tools to throw NPEs. > Driver works with SquirrelSQL (http://drill.apache.org/docs/using-jdbc/), but > fails with others (DbVisualizer for example). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DRILL-3262) Rename missed .impl.DrillDatabaseMetaData to .impl.DrillDatabaseMetaDataImpl to
[ https://issues.apache.org/jira/browse/DRILL-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) reassigned DRILL-3262: - Assignee: Daniel Barclay (Drill) (was: Parth Chandra) > Rename missed .impl.DrillDatabaseMetaData to .impl.DrillDatabaseMetaDataImpl > to > > > Key: DRILL-3262 > URL: https://issues.apache.org/jira/browse/DRILL-3262 > Project: Apache Drill > Issue Type: Bug >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > Fix For: 1.1.0 > > Attachments: DRILL-3262.2.patch.txt, DRILL-3262.3.patch.txt, > DRILL-3262.4.patch.txt, DRILL-3262.5.patch.txt, DRILL-3262.BASE.2.patch.txt, > DRILL-3262.BASE.3.patch.txt, DRILL-3262.BASE.4.patch.txt > > > Renamed current org.apache.drill.jdbc.impl.DrillDatabaseMetaData to > DrillDatabaseMetaDataImpl. (Was missed in DRILL-2089 move/renaming.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DRILL-2089) Split JDBC implementation out of org.apache.drill.jdbc, so that pkg. is place for doc.
[
https://issues.apache.org/jira/browse/DRILL-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) reassigned DRILL-2089:
-
Assignee: Daniel Barclay (Drill) (was: Parth Chandra)
> Split JDBC implementation out of org.apache.drill.jdbc, so that pkg. is place
> for doc.
> --
>
> Key: DRILL-2089
> URL: https://issues.apache.org/jira/browse/DRILL-2089
> Project: Apache Drill
> Issue Type: Improvement
> Components: Client - JDBC
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: Future
>
> Attachments: DRILL-2089.AllParts.1.patch.txt,
> DRILL-2089.Pt1.1.patch.txt, DRILL-2089.Pt2.1.patch.txt,
> DRILL-2089.Pt3.1.patch.txt, DRILL-2089.Pt4.1.patch.txt,
> DRILL-2089.Pt5.1.patch.txt, DRILL-2089.Pt6.1.patch.txt,
> DRILL-2089.Pt7.1.patch.txt
>
>
> The JDBC implementation classes and interfaces that are not part of Drill's
> published JDBC interface should be moved out of package org.apache.drill.jdbc.
> This will support using Javadoc to produce end-user documentation of
> Drill-specific JDBC API behavior (e.g., what's implemented or not, plus any
> extensions), and keep clear what is part of Drill's published JDBC interface
> vs. what is not (i.e., items that are technically accessible (public or
> protected) but _not_ meant to be used by Drill users).
> Parts:
> 1. Move most classes and packages in {{org.apache.drill.jdbc}} (e.g.,
> {{DrillHandler}}, {{DrillConnectionImpl}}) to an implementation package
> (e.g., {{org.apache.drill.jdbc.impl}}).
> 2. Split the current {{org.apache.drill.jdbc.Driver}} into a
> published-interface portion still at {{org.apache.drill.jdbc.Driver}} plus an
> implementation portion at {{org.apache.drill.jdbc.impl.DriverImpl}}.
> ({{org.apache.drill.jdbc.Driver}} would expose only the published interface
> (e.g., its constructor and methods from {{java.sql.Driver}}).
> {{org.apache.drill.jdbc.impl.DriverImpl}} would contain methods that are not
> part of Drill's published JDBC interface (including methods that need to be
> public or protected because of using Avatica but which shouldn't be used by
> Drill users).)
> 3. As needed (for Drill extensions and for documentation), create
> Drill-specific interfaces extending standard JDBC interfaces.
> For example, to create a place for documenting Drill-specific behavior of
> methods defined in {{java.sql.Connection}}, create an interface, e.g.,
> {{org.apache.drill.jdbc.DrillConnection}}, that extends interface
> {{java.sql.Connection}}, adjust the internal implementation class in
> {{org.apache.drill.jdbc.impl}} to implement that Drill-specified interface
> rather than directly implementing {{java.sql.Connection}}, and then add a
> method declaration with the Drill-specific documentation to the
> Drill-specific subinterface.
> 4. In Drill-specific interfaces created per part 3, _consider_ using
> co-variant return types to narrow return types to the Drill-specific
> interfaces.
> For example: {{java.sql.Connection}}'s {{createStatement()}} method returns
> type {{java.sql.Statement}}. Drill's implementation of that method will
> always return a Drill-specific implementation of {{java.sql.Statement}},
> which will also be an implementation of the Drill-specific interface that
> extends {{java.sql.Statement}}. Therefore, the Drill-specific {{Connection}}
> interface can re-declare {{createStatement()}} as returning the
> Drill-specific {{Statement}} interface type (because the Drill-specific
> {{Statement}} type is a subtype of {{java.sql.Statement}}).
> That would likely make it easier for client code to access any Drill
> extension methods: Although the client might have to cast or do something
> else special to get to the first Drill-specific interface or class, it could
> traverse to other objects (e.g., from connection to statement, from statement
> to result set, etc.) still using Drill-specific types, not needing casts or
> whatever as each step.
> Note: Steps 1 and 2 have already been prototyped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (DRILL-2839) ODBC Driver Doc to point to latest available Driver, also provide compatibility matrix for Drill and ODBC version
[ https://issues.apache.org/jira/browse/DRILL-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristine Hahn reassigned DRILL-2839: Assignee: Kristine Hahn (was: Bridget Bevens) > ODBC Driver Doc to point to latest available Driver, also provide > compatibility matrix for Drill and ODBC version > - > > Key: DRILL-2839 > URL: https://issues.apache.org/jira/browse/DRILL-2839 > Project: Apache Drill > Issue Type: Improvement > Components: Documentation >Reporter: Andries Engelbrecht >Assignee: Kristine Hahn > > On the ODBC documentation page the links to the ODBC drivers are hard linked > to the .0618 version of the drivers. > http://drill.apache.org/docs/step-1-install-the-mapr-drill-odbc-driver-on-windows/ > It may be better to point to the latest drivers available in the MapR > packages directory here. > http://package.mapr.com/tools/MapR-ODBC/MapR_Drill/MapRDrill_odbc/ > Challenge is to match the version of the ODBC driver that match the Drill > version. It may be good to add a compatibility matrix on the doc webpage to > identify the appropriate ODBC driver and Drill version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3305) DrillOptiq should raise appropriate error message while dealing with unknown RexNode
[ https://issues.apache.org/jira/browse/DRILL-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590698#comment-14590698 ] Aman Sinha commented on DRILL-3305: --- +1 for the patch. Pls populate the component field of this JIRA. > DrillOptiq should raise appropriate error message while dealing with unknown > RexNode > > > Key: DRILL-3305 > URL: https://issues.apache.org/jira/browse/DRILL-3305 > Project: Apache Drill > Issue Type: Bug >Reporter: Mehant Baid >Assignee: Mehant Baid > Fix For: 1.1.0 > > Attachments: DRILL-3305.patch > > > Currently for certain types of RexNodes (RexOver, RexCorrelVariable) > DrillOptiq does not convert it to the equivalent logical expressions. In that > case we simply return a NullExpression (minor type: Null) and we error out > later in execution when we try to allocate a vector with minor type Null. We > should error out early in DrillOptiq that there was a planning issue > indicating the particular RexNode that wasn't handled correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2003) bootstrap-storage-plugins.json is not merged properly
[ https://issues.apache.org/jira/browse/DRILL-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Altekruse updated DRILL-2003: --- Fix Version/s: (was: 1.1.0) 1.2.0 > bootstrap-storage-plugins.json is not merged properly > - > > Key: DRILL-2003 > URL: https://issues.apache.org/jira/browse/DRILL-2003 > Project: Apache Drill > Issue Type: Bug > Components: Metadata >Affects Versions: 0.7.0 >Reporter: Rahul Challapalli >Assignee: Jason Altekruse > Fix For: 1.2.0 > > > Drill not picking up the bootstrap-storage-plugins.json from the conf > directory. I made sure that the Zookeeper's drill directory is empty and the > conf directory is in the classpath. > It looks like there is an issue with the merge with the same file in the jar > file provided with drill. > This worked with 0.6.0 but seems to be broken with the current 0.7.0 release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3220) IOB Exception when using constants in window functions
[
https://issues.apache.org/jira/browse/DRILL-3220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aman Sinha updated DRILL-3220:
--
Assignee: Deneche A. Hakim (was: Aman Sinha)
> IOB Exception when using constants in window functions
> --
>
> Key: DRILL-3220
> URL: https://issues.apache.org/jira/browse/DRILL-3220
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.0.0
> Environment: faec150598840c40827e6493992d81209aa936da
>Reporter: Khurram Faraaz
>Assignee: Deneche A. Hakim
> Labels: window_function
> Fix For: 1.1.0
>
> Attachments: DRILL-3220.1.patch.txt, DRILL-3220.2.patch.txt,
> DRILL-3220.3.patch.txt
>
>
> The following query should run, but it throws an IndexOutOfBoundsException
> instead:
> {code}
> 0: jdbc:drill:schema=dfs.tmp> select count(1) over(partition by columns[1]
> order by columns[0]) from `time_data.csv`;
> Error: SYSTEM ERROR: java.lang.IndexOutOfBoundsException: index (2) must be
> less than size (2)
> [Error Id: ddcd3316-e906-4193-8e55-e208c3cda32d on centos-03.qa.lab:31010]
> (state=,code=0)
> {code}
> Stack trace from drillbit.log
> {code}
> org.apache.drill.exec.work.foreman.ForemanException: Unexpected exception
> during fragment initialization: index (2) must be less than size (2)
> at org.apache.drill.exec.work.foreman.Foreman.run(Foreman.java:251)
> [drill-java-exec-1.0.0-mapr-r1-rebuffed.jar:1.0.0-mapr-r1]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_45]
> Caused by: java.lang.IndexOutOfBoundsException: index (2) must be less than
> size (2)
> at
> com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:305)
> ~[guava-14.0.1.jar:na]
> at
> com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:284)
> ~[guava-14.0.1.jar:na]
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:81)
> ~[guava-14.0.1.jar:na]
> at org.apache.calcite.util.Pair$6.get(Pair.java:335)
> ~[calcite-core-1.1.0-drill-r7.jar:1.1.0-drill-r7]
> at
> org.apache.drill.exec.planner.physical.WindowPrel.toDrill(WindowPrel.java:112)
> ~[drill-java-exec-1.0.0-mapr-r1-rebuffed.jar:1.0.0-mapr-r1]
> at
> org.apache.drill.exec.planner.physical.WindowPrel.getPhysicalOperator(WindowPrel.java:89)
> ~[drill-java-exec-1.0.0-mapr-r1-rebuffed.jar:1.0.0-mapr-r1]
> at
> org.apache.drill.exec.planner.physical.ProjectPrel.getPhysicalOperator(ProjectPrel.java:55)
> ~[drill-java-exec-1.0.0-mapr-r1-rebuffed.jar:1.0.0-mapr-r1]
> at
> org.apache.drill.exec.planner.physical.ProjectPrel.getPhysicalOperator(ProjectPrel.java:55)
> ~[drill-java-exec-1.0.0-mapr-r1-rebuffed.jar:1.0.0-mapr-r1]
> at
> org.apache.drill.exec.planner.physical.ScreenPrel.getPhysicalOperator(ScreenPrel.java:51)
> ~[drill-java-exec-1.0.0-mapr-r1-rebuffed.jar:1.0.0-mapr-r1]
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.convertToPop(DefaultSqlHandler.java:447)
> ~[drill-java-exec-1.0.0-mapr-r1-rebuffed.jar:1.0.0-mapr-r1]
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.getPlan(DefaultSqlHandler.java:192)
> ~[drill-java-exec-1.0.0-mapr-r1-rebuffed.jar:1.0.0-mapr-r1]
> at
> org.apache.drill.exec.planner.sql.DrillSqlWorker.getPlan(DrillSqlWorker.java:177)
> ~[drill-java-exec-1.0.0-mapr-r1-rebuffed.jar:1.0.0-mapr-r1]
> at
> org.apache.drill.exec.work.foreman.Foreman.runSQL(Foreman.java:902)
> [drill-java-exec-1.0.0-mapr-r1-rebuffed.jar:1.0.0-mapr-r1]
> at org.apache.drill.exec.work.foreman.Foreman.run(Foreman.java:240)
> [drill-java-exec-1.0.0-mapr-r1-rebuffed.jar:1.0.0-mapr-r1]
> ... 3 common frames omitted
> 2015-05-30 01:22:07,372 [2a96ef40-25ae-aedc-9f56-2da309e4d911:foreman] INFO
> o.a.drill.exec.work.foreman.Foreman - foreman cleaning up.
> 2015-05-30 01:22:07,373 [2a96ef40-25ae-aedc-9f56-2da309e4d911:foreman] ERROR
> o.a.d.c.exceptions.UserException - SYSTEM ERROR:
> java.lang.IndexOutOfBoundsException: index (2) must be less than size (2)
> [Error Id: ddcd3316-e906-4193-8e55-e208c3cda32d on centos-03.qa.lab:31010]
> org.apache.drill.common.exceptions.UserException: SYSTEM ERROR:
> java.lang.IndexOutOfBoundsException: index (2) must be less than size (2)
> [Error Id: ddcd3316-e906-4193-8e55-e208c3cda32d on centos-03.qa.lab:31010]
> at
> org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:522)
> ~[drill-common-1.0.0-mapr-r1-rebuffed.jar:
[jira] [Updated] (DRILL-3305) DrillOptiq should raise appropriate error message while dealing with unknown RexNode
[ https://issues.apache.org/jira/browse/DRILL-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mehant Baid updated DRILL-3305: --- Fix Version/s: 1.1.0 > DrillOptiq should raise appropriate error message while dealing with unknown > RexNode > > > Key: DRILL-3305 > URL: https://issues.apache.org/jira/browse/DRILL-3305 > Project: Apache Drill > Issue Type: Bug >Reporter: Mehant Baid >Assignee: Mehant Baid > Fix For: 1.1.0 > > Attachments: DRILL-3305.patch > > > Currently for certain types of RexNodes (RexOver, RexCorrelVariable) > DrillOptiq does not convert it to the equivalent logical expressions. In that > case we simply return a NullExpression (minor type: Null) and we error out > later in execution when we try to allocate a vector with minor type Null. We > should error out early in DrillOptiq that there was a planning issue > indicating the particular RexNode that wasn't handled correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3305) DrillOptiq should raise appropriate error message while dealing with unknown RexNode
[ https://issues.apache.org/jira/browse/DRILL-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mehant Baid updated DRILL-3305: --- Attachment: DRILL-3305.patch [~amansinha100] can you please review > DrillOptiq should raise appropriate error message while dealing with unknown > RexNode > > > Key: DRILL-3305 > URL: https://issues.apache.org/jira/browse/DRILL-3305 > Project: Apache Drill > Issue Type: Bug >Reporter: Mehant Baid >Assignee: Mehant Baid > Attachments: DRILL-3305.patch > > > Currently for certain types of RexNodes (RexOver, RexCorrelVariable) > DrillOptiq does not convert it to the equivalent logical expressions. In that > case we simply return a NullExpression (minor type: Null) and we error out > later in execution when we try to allocate a vector with minor type Null. We > should error out early in DrillOptiq that there was a planning issue > indicating the particular RexNode that wasn't handled correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-3305) DrillOptiq should raise appropriate error message while dealing with unknown RexNode
Mehant Baid created DRILL-3305: -- Summary: DrillOptiq should raise appropriate error message while dealing with unknown RexNode Key: DRILL-3305 URL: https://issues.apache.org/jira/browse/DRILL-3305 Project: Apache Drill Issue Type: Bug Reporter: Mehant Baid Assignee: Mehant Baid Currently for certain types of RexNodes (RexOver, RexCorrelVariable) DrillOptiq does not convert it to the equivalent logical expressions. In that case we simply return a NullExpression (minor type: Null) and we error out later in execution when we try to allocate a vector with minor type Null. We should error out early in DrillOptiq that there was a planning issue indicating the particular RexNode that wasn't handled correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3266) Drill's hive storage plugin cannot find RegexSerDe
[
https://issues.apache.org/jira/browse/DRILL-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Venki Korukanti updated DRILL-3266:
---
Fix Version/s: 1.1.0
> Drill's hive storage plugin cannot find RegexSerDe
> --
>
> Key: DRILL-3266
> URL: https://issues.apache.org/jira/browse/DRILL-3266
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Hive
>Reporter: Rahul Challapalli
>Assignee: Venki Korukanti
> Fix For: 1.1.0
>
> Attachments: DRILL-3266-1.patch, apache_log.txt, error.log
>
>
> git.commit.id.abbrev=5f26b8b
> HIve DDL :
> {code}
> CREATE EXTERNAL TABLE IF NOT EXISTS hive_storage.raw_access_log(
> remote_host STRING,
> remote_logname STRING,
> remote_user STRING,
> request_time STRING,
> first_line STRING,
> http_status STRING,
> bytes STRING
> )
> ROW FORMAT SERDE 'org.apache.hadoop.hive.contrib.serde2.RegexSerDe'
> WITH SERDEPROPERTIES (
> "input.regex" = "([^ ]*) ([^ ]*) ([^ ]*) (-|\\[[^\\]]*\\]) ([^
> \"]*|\"[^\"]*\") (-|[0-9]*) (-|[0-9]*)",
> "output.format.string" = "%1$s %2$s %3$s %4$s %5$s %6$s %7$s"
> )
> LOCATION '/drill/testdata/hive_storage/raw_access_log';
> {code}
> When I try to query this table from sqlline, I get the below error
> {code}
> 0: jdbc:drill:schema=dfs_eea> select * from raw_access_log;
> Error: PARSE ERROR: MetaException(message:java.lang.ClassNotFoundException
> Class org.apache.hadoop.hive.contrib.serde2.RegexSerDe not found)
> [Error Id: 5961c4c4-1cf5-495c-9c8a-0616b58d2488 on qa-node190.qa.lab:31010]
> (state=,code=0)
> {code}
> The query works from hive without any issues. I attached the data set and the
> error log
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (DRILL-2991) Implement receivingFragmentFinished() method in BroadcastSenderRootExec
[ https://issues.apache.org/jira/browse/DRILL-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam reassigned DRILL-2991: -- Assignee: Sudheesh Katkam > Implement receivingFragmentFinished() method in BroadcastSenderRootExec > --- > > Key: DRILL-2991 > URL: https://issues.apache.org/jira/browse/DRILL-2991 > Project: Apache Drill > Issue Type: Bug >Reporter: Sudheesh Katkam >Assignee: Sudheesh Katkam > Fix For: 1.1.0 > > > BroadCastSenderRootExec does not implement the receivingFragmentFinished() > method i.e. the sender ignores the receiver's request not to send more > batches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3298) Wrong result with SUM window function and order by without partition by in the OVER clause
[
https://issues.apache.org/jira/browse/DRILL-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deneche A. Hakim updated DRILL-3298:
Assignee: Aman Sinha (was: Deneche A. Hakim)
> Wrong result with SUM window function and order by without partition by in
> the OVER clause
> --
>
> Key: DRILL-3298
> URL: https://issues.apache.org/jira/browse/DRILL-3298
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Aman Sinha
>Priority: Critical
> Labels: window_function
> Fix For: 1.1.0
>
> Attachments: DRILL-3298.1.patch.txt, j1.tar, test.res
>
>
> This query returns incorrect result when planner.slice_target = 1
> {code}
> select
> j1.c_integer,
> sum(j1.c_integer) over w
> from j1
> window w as (order by c_integer desc)
> order by
> 1, 2;
> {code}
> Query plan with planner.slice_target = 1
> {noformat}
> 00-01 Project(c_integer=[$0], EXPR$1=[$1])
> 00-02SingleMergeExchange(sort0=[0 ASC], sort1=[1 ASC])
> 01-01 SelectionVectorRemover
> 01-02Sort(sort0=[$0], sort1=[$1], dir0=[ASC], dir1=[ASC])
> 01-03 Project(c_integer=[$0], EXPR$1=[$1])
> 01-04HashToRandomExchange(dist0=[[$0]], dist1=[[$1]])
> 02-01 UnorderedMuxExchange
> 03-01Project(c_integer=[$0], EXPR$1=[$1],
> E_X_P_R_H_A_S_H_F_I_E_L_D=[castInt(hash64AsDouble($1, hash64AsDouble($0)))])
> 03-02 Project(c_integer=[$0], EXPR$1=[CASE(>($1, 0),
> CAST($2):ANY, null)])
> 03-03Window(window#0=[window(partition {} order by [0
> DESC] range between UNBOUNDED PRECEDING and CURRENT ROW aggs [COUNT($0),
> $SUM0($0)])])
> 03-04 SelectionVectorRemover
> 03-05Sort(sort0=[$0], dir0=[DESC])
> 03-06 Scan(groupscan=[ParquetGroupScan
> [entries=[ReadEntryWithPath [path=maprfs:///drill/testdata/subqueries/j1]],
> selectionRoot=/drill/testdata/subqueries/j1, numFiles=1,
> columns=[`c_integer`]]])
> {noformat}
> Query plan with planner.slice_target = 10;
> {noformat}
> 00-01 Project(c_integer=[$0], EXPR$1=[$1])
> 00-02SelectionVectorRemover
> 00-03 Sort(sort0=[$0], sort1=[$1], dir0=[ASC], dir1=[ASC])
> 00-04Project(c_integer=[$0], EXPR$1=[CASE(>($1, 0), CAST($2):ANY,
> null)])
> 00-05 Window(window#0=[window(partition {} order by [0 DESC]
> range between UNBOUNDED PRECEDING and CURRENT ROW aggs [COUNT($0),
> $SUM0($0)])])
> 00-06SelectionVectorRemover
> 00-07 Sort(sort0=[$0], dir0=[DESC])
> 00-08Scan(groupscan=[ParquetGroupScan
> [entries=[ReadEntryWithPath [path=maprfs:///drill/testdata/subqueries/j1]],
> selectionRoot=/drill/testdata/subqueries/j1, numFiles=1,
> columns=[`c_integer`]]])
> {noformat}
> Attached:
> * table j1
> * test.res - result generated with postgres
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2763) [umbrella] Implement INFORMATION_SCHEMA.COLUMNS enough for relevant tools
[
https://issues.apache.org/jira/browse/DRILL-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2763:
--
Summary: [umbrella] Implement INFORMATION_SCHEMA.COLUMNS enough for
relevant tools (was: Implement INFORMATION_SCHEMA.COLUMNS enough for relevant
tools [umbrella])
> [umbrella] Implement INFORMATION_SCHEMA.COLUMNS enough for relevant tools
> -
>
> Key: DRILL-2763
> URL: https://issues.apache.org/jira/browse/DRILL-2763
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Information Schema
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: 1.1.0
>
>
> [TBD: intro.]
> *A. {{COLUMNS}} columns existing in Drill that are not compliant with
> standard SQL*:
> 1. *TDB*: {{TABLE_NAME}} holds the original form of the identifier but
> _might_ need to be uppercased here to be compliant (or possibly internal
> matching queries (e.g., for JDBC's getColumns(...)) could be
> case-insensitive).
> 2. *TDB*: {{COLUMN_NAME}} holds the original form of the identifier but
> _might_ need to be uppercased here to be compliant (or possibly internal
> matching queries (e.g., for JDBC's getColumns(...)) could be
> case-insensitive).
> 3. \[3216] {{ORDINAL_POSITION}} values are zero-based rather than being
> one-based.
> 4. \[3216] {{CHARACTER_MAXIMUM_LENGTH}}, {{NUMERIC_PRECISION_RADIX}},
> {{NUMERIC_SCALE}}, and {{NUMERIC_PRECISION}} use {{-1}} instead of {{NULL}}
> for the "not-applicable" case.
> 5. \[3216] {{NUMERIC_PRECISION}} for non-{{DECIMAL}}/{{NUMERIC}} exact
> numeric types (e.g., {{INTEGER}}) and approximate numeric types (e.g.,
> {{DOUBLE}}) is {{-1}} (logical null) instead of the specified values.
> 6. \[3216] {{NUMERIC_SCALE}} for non-{{DECIMAL}}/{{NUMERIC}} exact numeric
> types is {{-1}} instead of {{0}}.
> 7. \[3216] {{NUMERIC_SCALE}} for approximate numeric types is {{-1}} instead
> of the number of bits of precision (24 and 53(?)).
> 8. \[3216] {{NUMERIC_PRECISION_RADIX}} for integral exact numeric types is
> {{-1}} instead of {{10}}.
> 9. \[3216] {{NUMERIC_PRECISION_RADIX}} for approximate exact numeric types is
> {{-1}} instead of {{2}}.
> 10. \[3216] {{CHARACTER_MAXIMUM_LENGTH}} for types {{CHAR}}, {{BINARY}}, and
> {{VAR BINARY}} is {{-1}} instead of the corresponding length.
> 11. \[3216] {{DATA_TYPE}} values for {{INTERVAL}} with {{YEAR}} and/or
> {{MONTH}} and for {{INTERVAL}} with {{DAY}}, {{HOUR}}, {{MINUTE}}, and/or
> {{SECOND}} are "{{INTERVAL_YEAR_MONTH}}" and "{{INTERVAL_DATA_TIME}}",
> respectively, instead of the data type name "{{INTERVAL}}".
> 12. \[3216] {{DATA_TYPE}} values for non-atomic types seem to be type
> descriptors ({{}} syntax; e.g., "{{VARCHAR(65536) ARRAY}}")
> instead of just data type names (e.g., "{{ARRAY}}").
> *B. Standard {{COLUMNS}} columns that don't exist in Drill and that probably
> are more relevant*:
> 1. \[3216] {{CHARACTER_OCTET_LENGTH}} does not exist. (Drill's JDBC driver
> needs to return this, and currently tries to compute it itself.)
> 2. \[3216] {{DATETIME_PRECISION}} does not exist. (Drill's JDBC driver
> probably needs it to compute its {{getColumns()}}'s {{COLUMN_SIZE}}
> correctly.)
> 3. \[3216] {{INTERVAL_TYPE}} does not exist. (Drill's JDBC driver needs this
> to compute its {{getColumns()}}'s {{COLUMN_SIZE}} correctly once
> {{COLUMNS.DATA_TYPE}} is correct.}
> 4. \[3216] {{INTERVAL_PRECISION}} does not exist. (Drill's JDBC driver needs
> this to compute its {{getColumns()}}'s {{COLUMN_SIZE}} correctly.)
> \[TBD]:
> 5. {{MAXIMUM_CARDINALITY}} does not exist. (This might be relevant for
> JDBC's {{getColumns()}}'s {{COLUMN_SIZE}}.)
> *C. Standard {{COLUMNS}} columns that don't exist in Drill but are less
> likely to be relevant (listed for completeness)*:
> - \[3216] {{COLUMN_DEFAULT}}
> - {{CHARACTER_SET_CATALOG}}
> - {{CHARACTER_SET_SCHEMA}}
> - {{CHARACTER_SET_NAME}}
> - {{COLLATION_CATALOG}}
> - {{COLLATION_SCHEMA}}
> - {{COLLATION_NAME}}
> - {{DOMAIN_CATALOG}}
> - {{DOMAIN_SCHEMA}}
> - {{DOMAIN_NAME}}
> - {{UDT_CATALOG}}
> - {{UDT_SCHEMA}}
> - {{UDT_NAME}}
> - {{SCOPE_CATALOG}}
> - {{SCOPE_SCHEMA}}
> - {{SCOPE_NAME}}
> - {{DTD_IDENTIFIER}}
> - {{IS_SELF_REFERENCING}}
> - {{IS_IDENTITY}}
> - {{IDENTITY_GENERATION}}
> - {{IDENTITY_START}}
> - {{IDENTITY_INCREMENT}}
> - {{IDENTITY_MAXIMUM}}
> - {{IDENTITY_MINIMUM}}
> - {{IDENTITY_CYCLE}}
> - {{IS_GENERATED}}
> - {{GENERATION_EXPRESSION}}
> - {{IS_SYSTEM_TIME_PERIOD_START}}
> - {{IS_SYSTEM_TIME_PERIOD_END}}
> - {{SYSTEM_TIME_PERIOD_TIMESTAMP_GENERATION}}
> - {{IS_UPDATABLE}}
> - {{DECLARED_DATA_TYPE}}
> - {{DECLARED_NUMERIC_PRECISION}}
> - {{DECLARED_NUMERIC_SCALE}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3243) Need a better error message - Use of alias in window function definition
[
https://issues.apache.org/jira/browse/DRILL-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deneche A. Hakim updated DRILL-3243:
Attachment: DRILL-3243.1.patch.txt
fixed error message.
added unit test
all unit tests are passing
> Need a better error message - Use of alias in window function definition
>
>
> Key: DRILL-3243
> URL: https://issues.apache.org/jira/browse/DRILL-3243
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.0.0
>Reporter: Khurram Faraaz
>Assignee: Deneche A. Hakim
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: DRILL-3243.1.patch.txt
>
>
> Need a better error message when we use alias for window definition in query
> that uses window functions. for example, OVER(PARTITION BY columns[0] ORDER
> BY columns[1]) tmp, and if alias "tmp" is used in the predicate we need a
> message that says, column "tmp" does not exist, that is how it is in Postgres
> 9.3
> Postgres 9.3
> {code}
> postgres=# select count(*) OVER(partition by type order by id) `tmp` from
> airports where tmp is not null;
> ERROR: column "tmp" does not exist
> LINE 1: ...ect count(*) OVER(partition by type order by id) `tmp` from ...
> ^
> {code}
> Drill 1.0
> {code}
> 0: jdbc:drill:schema=dfs.tmp> select count(*) OVER(partition by columns[2]
> order by columns[0]) tmp from `airports.csv` where tmp is not null;
> Error: SYSTEM ERROR: java.lang.IllegalArgumentException: Selected column(s)
> must have name 'columns' or must be plain '*'
> Fragment 0:0
> [Error Id: 66987b81-fe50-422d-95e4-9ce61c873584 on centos-02.qa.lab:31010]
> (state=,code=0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2680) [umbrella] Assertions, thrown AssertionErrors should include some message text
[ https://issues.apache.org/jira/browse/DRILL-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-2680: -- Summary: [umbrella] Assertions, thrown AssertionErrors should include some message text (was: Assertions, thrown AssertionErrors should include some message text [umbrella]) > [umbrella] Assertions, thrown AssertionErrors should include some message text > -- > > Key: DRILL-2680 > URL: https://issues.apache.org/jira/browse/DRILL-2680 > Project: Apache Drill > Issue Type: Task >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > Fix For: 1.2.0 > > > Drill seems to have a lot of "assert ..." statements and "throw new > AssertionError()" cases that include no message text. > Many of them should at least include a phrase or two about what's wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2420) [umbrella] Identify, fix DatabaseMetaData.getColumns() bugs
[
https://issues.apache.org/jira/browse/DRILL-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2420:
--
Summary: [umbrella] Identify, fix DatabaseMetaData.getColumns() bugs (was:
Identify, fix DatabaseMetaData.getColumns() bugs [umbrella])
> [umbrella] Identify, fix DatabaseMetaData.getColumns() bugs
> ---
>
> Key: DRILL-2420
> URL: https://issues.apache.org/jira/browse/DRILL-2420
> Project: Apache Drill
> Issue Type: Task
> Components: Client - JDBC, Metadata
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: 1.1.0
>
>
> Drill's implementation of {{DatabaseMetaData.getColumns(...)}} (currently at
> {{org.apache.drill.jdbc.MetaImpl.getColumns()}}) doesn't match the JDBC
> specification (the Javadoc documentation for
> {{DatabaseMetaData.getColumns(...)}} (as of Java 7)). In the returned
> {{ResultSet}}:
> 1. -Column {{DATA_TYPE}} is of type {{VARCHAR}} (containing the type name)
> rather than being of type {{INTEGER}} (containing values per
> {{java.sql.Types.*}}).- \[Fixed by DRILL-2128.\]
> 2. -Column {{TYPE_NAME}} is missing.- \[Fixed by DRILL-2128.\]
> 3. -Column {{COLUMN_SIZE}} is missing.- \[Fixed by DRILL-2465.\]
> 4. -(Columns after {{DATA_TYPE}} are at incorrect indexes.)- \[Fixed by
> DRILL-2465.\]
> 5. -Column {{DECIMAL_DIGITS}} is misnamed {{DECIMAL_PRECISION}}.- \[Fixed by
> DRILL-2465.\]
> 6. -Column {{REMARKS}} is an empty string, but probably should be {{NULL}}.-
> \[Fixed by DRILL-2465.\]
> 7. -Column {{COLUMN_DEF}} is an empty string, but probably should be
> {{NULL}}.- \[Fixed by DRILL-2465.\]
> 8. -Column {{CHAR_OCTET_LENGTH}} is always {{4}}, but should be "the maximum
> number of bytes in the _column_" for character types.- \[Fixed by
> DRILL-2465.\]
> 8.5 Column {{IS_NULLABLE}} seems to always return 'NO'.
> 9. -Column {{ORDINAL_POSITION}} is always {{1}}, but should be the index of
> the specific column.- \[Fixed by DRILL-2465.\]
> 10. Column {{IS_NULLABLE}} is {{'YES'}}, which doesn't seem to correspond to
> the value for {{NULLABLE}} ({{DatabaseMetaData.columnNullableUnknown}}).
> 11. -Column {{SCOPE_CATALOG}} is an empty string, but should be {{NULL}}.-
> \[Fixed by DRILL-2465.\]
> 12. -Column {{SCOPE_SCHEMA}} is an empty string, but should be {{NULL}}.-
> \[Fixed by DRILL-2465.\]
> 13. -Column {{SCOPE_TABLE}} is an empty string, but should be {{NULL}}.-
> \[Fixed by DRILL-2465.\]
> 14. -Column {{SOURCE_DATA_TYPE}} is an empty string, but should be {{NULL}}.-
> \[Fixed by DRILL-2465.\]
> Additional bugs or suspect behavior:
> - {{DECIMAL_DIGITS}}/{{DECIMAL_PRECISION}} is {{-1}} when it should be
> {{NULL}} (when not applicable).
> - -{{NUM_PREC_RADIX}} is {{-1}} when it probably should be {{NULL}} (when not
> applicable).- \[Fixed by DRILL-2465.\]
> (Other columns to check:
> Re {{BUFFER_LENGTH}}, {{SQL_DATA_TYPE}}, and {{SQL_DATETIME_SUB}}: When JDBC
> says a column is not used, are there any requirements on the values (e.g.,
> being {{NULL}})?
> Re {{IS_AUTOINCREMENT}}: Do we know that a column is not auto-incremented?
> If so, the value could be {{'NO'}} rather than an empty string.
> Re {{IS_GENERATEDCOLUMN}}: Do we know that a column is not generated? If
> so, the value could be {{'NO'}} rather than an empty string.
> (Re {{NULLABLE}} : Do know whether a column is nullable or not? If so, we
> could return the specific answer rather that just saying that it's unknown.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2436) [umbrella] Implement JDBC enough for relevant tools
[ https://issues.apache.org/jira/browse/DRILL-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-2436: -- Summary: [umbrella] Implement JDBC enough for relevant tools (was: Implement JDBC enough for relevant tools [umbrella]) > [umbrella] Implement JDBC enough for relevant tools > --- > > Key: DRILL-2436 > URL: https://issues.apache.org/jira/browse/DRILL-2436 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC, Metadata >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > Fix For: 1.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2470) [umbrella] Implement SMALLINT and TINYINT
[ https://issues.apache.org/jira/browse/DRILL-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-2470: -- Summary: [umbrella] Implement SMALLINT and TINYINT (was: Implement SMALLINT and TINYINT [umbrella]) > [umbrella] Implement SMALLINT and TINYINT > - > > Key: DRILL-2470 > URL: https://issues.apache.org/jira/browse/DRILL-2470 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Data Types >Reporter: Daniel Barclay (Drill) > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2480) [umbrella] Identify, fix INFORMATION_SCHEMA and JDBC metadata bugs
[
https://issues.apache.org/jira/browse/DRILL-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2480:
--
Summary: [umbrella] Identify, fix INFORMATION_SCHEMA and JDBC metadata bugs
(was: Identify, fix INFORMATION_SCHEMA and JDBC metadata bugs [umbrella])
> [umbrella] Identify, fix INFORMATION_SCHEMA and JDBC metadata bugs
> --
>
> Key: DRILL-2480
> URL: https://issues.apache.org/jira/browse/DRILL-2480
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC, Metadata
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: 1.1.0
>
>
> This DRILL-2480 is a second-level umbrella/tracking bug to group metadata
> bugs, including other umbrella/tracking bugs, whether in INFORMATION_SCHEMA
> or in the JDBC code that uses INFORMATION_SCHEMA.
> DRILL-2480 partly covers DRILL-2436 ("JDBC enough for relevant tools",
> including metadata).
> DRILL-2480 covers DRILL-2522 ("INFORMATION_SCHEMA enough for relevant tools").
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2395) Improve interpreted expression evaluation to only call the setup method once per batch
[ https://issues.apache.org/jira/browse/DRILL-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Altekruse updated DRILL-2395: --- Fix Version/s: (was: 1.1.0) 1.2.0 > Improve interpreted expression evaluation to only call the setup method once > per batch > -- > > Key: DRILL-2395 > URL: https://issues.apache.org/jira/browse/DRILL-2395 > Project: Apache Drill > Issue Type: Improvement > Components: Functions - Drill >Reporter: Jason Altekruse >Assignee: Jason Altekruse >Priority: Minor > Fix For: 1.2.0 > > > This enhancement request came out of the review for a patch for DRILL-2060. > Copied below is the discussion from there: > Jinfeng: > Do you have a plan to move setup() call into places such that setup() will be > called once for each VectorAccessible input? > In the code compile + evaluation model, doSetup() will be called per batch, > in stead of per row. > Jason: > I have started working on a fix for this. Its a little complicated with > setting constant inputs before the setup method is called. I'm trying to > figure out the best way to share code with the rest of the input passing used > in the EvalVisitor. Would you be okay with this being opened as an > enhancement request to be merged a little later? Considering the current use > of the interpreter this won't have an impact on any actual queries today. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2035) Add ability to cancel multiple queries
[ https://issues.apache.org/jira/browse/DRILL-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Altekruse updated DRILL-2035: --- Fix Version/s: (was: 1.1.0) 1.2.0 > Add ability to cancel multiple queries > -- > > Key: DRILL-2035 > URL: https://issues.apache.org/jira/browse/DRILL-2035 > Project: Apache Drill > Issue Type: New Feature > Components: Client - HTTP >Reporter: Neeraja >Assignee: Jason Altekruse > Fix For: 1.2.0 > > > Currently Drill UI allows canceling one query at a time. > This could be cumbersome to manage for scenarios using with BI tools which > generate multiple queries for a single action in the UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3303) Build doesn't support recent version of Java
[ https://issues.apache.org/jira/browse/DRILL-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590547#comment-14590547 ] Hanifi Gunes commented on DRILL-3303: - Drill does not "officially" support 1.8. For the time being I would recommend a downgrade if you face any issues. > Build doesn't support recent version of Java > > > Key: DRILL-3303 > URL: https://issues.apache.org/jira/browse/DRILL-3303 > Project: Apache Drill > Issue Type: Bug >Reporter: Levi Page > > I am unable to build drill. I get the following error: > Failed to execute goal > org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce > (validate_java_and_maven_version) on project drill-root: Some Enforcer rules > have failed. Look above for specific messages explaining why the rule failed. > -> [Help 1] > It looks like my java version is too recent. Do I need to install an old > version or should this be updated in the build configuration? > [WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequireJavaVersion failed > with message: > Detected JDK Version: 1.8.0-45 is not in the allowed range [1.7,1.8). > I followed these steps: > git clone https://github.com/apache/drill.git > mvn clean install -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3078) Tracking bug for ODBC doc changes from Simba
[ https://issues.apache.org/jira/browse/DRILL-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590526#comment-14590526 ] Kristine Hahn commented on DRILL-3078: -- Covered #8 on [Specifying Column Names|http://drill.apache.org/docs/browsing-data-and-defining-views/#specifying-column-names] and [Casting Data Requirements|http://drill.apache.org/docs/browsing-data-and-defining-views/#casting-data-requirements]. Seems like it's just a *really* brief summary of some of the Drill syntax. > Tracking bug for ODBC doc changes from Simba > > > Key: DRILL-3078 > URL: https://issues.apache.org/jira/browse/DRILL-3078 > Project: Apache Drill > Issue Type: Bug > Components: Documentation >Affects Versions: 1.0.0 >Reporter: Bob Rumsby >Assignee: Bob Rumsby > Fix For: 1.1.0 > > Attachments: Simba ODBC Driver for Apache Drill Install Guide-3.pdf, > Simba ODBC Driver for Apache Drill Install Guide-5.pdf > > > This bug tracks a list of items in the Simba Drill ODBC doc (from April 10) > that need to be updated (or may need to be updated) for Version 1.0. > 1. Links to latest ODBC drivers (Windows, Linux) > 2. "Verifying the Version Number" section not in our docs? > 3. Using Drill Explorer (Mac--was not working before, now works?) (Kris) > 4. Remove "as of 0.4" references from Using Explorer on Windows (Kris) > 5. Add Drill Explorer location to the table on the Installing Driver on Linux > page (Kris) > 6. NumberOfPrefetchBuffers option (advanced properties, prefetch or > prefetched is correct? Simba doc not consistent) (Kris) > 7. Driver Configuration Options and Advanced Properties topics are separated > in our navigation: why? (Kris) > 8. Features section of the Simba doc: do we cover all of this > somehow/somewhere? (Kris) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3304) improve org.apache.drill.exec.expr.TypeHelper error messages when UnsupportedOprationException is thrown
[ https://issues.apache.org/jira/browse/DRILL-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deneche A. Hakim updated DRILL-3304: Assignee: Hanifi Gunes (was: Deneche A. Hakim) > improve org.apache.drill.exec.expr.TypeHelper error messages when > UnsupportedOprationException is thrown > > > Key: DRILL-3304 > URL: https://issues.apache.org/jira/browse/DRILL-3304 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Data Types >Affects Versions: 1.0.0 >Reporter: Deneche A. Hakim >Assignee: Hanifi Gunes >Priority: Minor > Fix For: 1.1.0 > > Attachments: DRILL-3304.1.patch.txt > > > TypeHelper contains several helper methods that take as parameter a > MajorType. When the received type is incorrect, most helper methods will > throw an UnsupportedOperationException with an empty message. > The purpose of this Jira is to add proper messages to the thrown exceptions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DRILL-3078) Tracking bug for ODBC doc changes from Simba
[
https://issues.apache.org/jira/browse/DRILL-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575405#comment-14575405
]
Kristine Hahn edited comment on DRILL-3078 at 6/17/15 6:56 PM:
---
{quote}
6. NumberOfPrefetchBuffers option (advanced properties, prefetch or prefetched
is correct? Simba doc not consistent)
{quote}
Done.
{quote}
2. "Verifying the Version Number" section not in our docs?
3. Using Drill Explorer (Mac--was not working before, now works?)
5. Add Drill Explorer location to the table on the Installing Driver on Linux
page
7. Driver Configuration Options and Advanced Properties topics are separated in
our navigation: why?
{quote}
Done, please see the following published docs:
#2
* Linux: [Check the MapR Drill ODBC Driver
version|http://drill.apache.org/docs/installing-the-driver-on-linux/#step-3:-check-the-mapr-drill-odbc-driver-version]
* Mac OS X: [Check the MapR Drill ODBC Driver
version|http://drill.apache.org/docs/installing-the-driver-on-mac-os-x/#step-3:-check-the-mapr-drill-odbc-driver-version]
* Windows: the version appears in Apps, as pictured and stated in [Verify the
Installation|http://drill.apache.org/docs/installing-the-driver-on-windows/#step-3:-verify-the-installation]
#3
* Linux: [Connecting Drill Explorer to Data on
Linux|http://drill.apache.org/docs/connecting-drill-explorer-to-data/#connecting-drill-explorer-to-data-on-linux]
* Mac OS X: [Connecting Drill Explorer to Data obn Mac OS
X|http://drill.apache.org/docs/connecting-drill-explorer-to-data/#connecting-drill-explorer-to-data-on-mac-os-x]
* Windows: [Starting Drill Explorer on
Windows|http://drill.apache.org/docs/connecting-drill-explorer-to-data/#starting-drill-explorer-on-windows]
All platforms: [Browsing Data and Defining
Views|http://drill.apache.org/docs/browsing-data-and-defining-views]
#5
Location of Drill Explorer on each platform is included in [Connecting Drill
Explorer to
Data|http://drill.apache.org/docs/connecting-drill-explorer-to-data/Drill
Explorer]
#7
Reorganized info. [ODBC Configuration
Reference|http://drill.apache.org/docs/odbc-configuration-reference] presents
options that are used on all platforms and includes a section about [Advanced
Properties|http://drill.apache.org/docs/odbc-configuration-reference/#advanced-properties]
was (Author: krishahn):
{quote}
6. NumberOfPrefetchBuffers option (advanced properties, prefetch or prefetched
is correct? Simba doc not consistent)
{quote}
Done.
{quote}
2. "Verifying the Version Number" section not in our docs?
3. Using Drill Explorer (Mac--was not working before, now works?)
5. Add Drill Explorer location to the table on the Installing Driver on Linux
page
7. Driver Configuration Options and Advanced Properties topics are separated in
our navigation: why?
{quote}
In progress.
> Tracking bug for ODBC doc changes from Simba
>
>
> Key: DRILL-3078
> URL: https://issues.apache.org/jira/browse/DRILL-3078
> Project: Apache Drill
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 1.0.0
>Reporter: Bob Rumsby
>Assignee: Bob Rumsby
> Fix For: 1.1.0
>
> Attachments: Simba ODBC Driver for Apache Drill Install Guide-3.pdf,
> Simba ODBC Driver for Apache Drill Install Guide-5.pdf
>
>
> This bug tracks a list of items in the Simba Drill ODBC doc (from April 10)
> that need to be updated (or may need to be updated) for Version 1.0.
> 1. Links to latest ODBC drivers (Windows, Linux)
> 2. "Verifying the Version Number" section not in our docs?
> 3. Using Drill Explorer (Mac--was not working before, now works?) (Kris)
> 4. Remove "as of 0.4" references from Using Explorer on Windows (Kris)
> 5. Add Drill Explorer location to the table on the Installing Driver on Linux
> page (Kris)
> 6. NumberOfPrefetchBuffers option (advanced properties, prefetch or
> prefetched is correct? Simba doc not consistent) (Kris)
> 7. Driver Configuration Options and Advanced Properties topics are separated
> in our navigation: why? (Kris)
> 8. Features section of the Simba doc: do we cover all of this
> somehow/somewhere? (Kris)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2851) Memory LEAK - FLATTEN function fails when input array has 99,999 integer type elements
[
https://issues.apache.org/jira/browse/DRILL-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanifi Gunes updated DRILL-2851:
Assignee: Mehant Baid (was: Venki Korukanti)
> Memory LEAK - FLATTEN function fails when input array has 99,999 integer type
> elements
> --
>
> Key: DRILL-2851
> URL: https://issues.apache.org/jira/browse/DRILL-2851
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 0.9.0
> Environment: 64e3ec52b93e9331aa5179e040eca19afece8317 | DRILL-2611:
> value vectors should report valid value count | 16.04.2015 @ 13:53:34 EDT
>Reporter: Khurram Faraaz
>Assignee: Mehant Baid
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: Jsn_Arry100.json
>
>
> FLATTEN function does not return results when input array has 99,999 elements
> of type integer. Test was run on 4 node cluster on CentOS.
> Looks like there is a memory leak somewhere because I see this message in the
> stack trace. "Failure while closing accountor".
> {code}
> 0: jdbc:drill:> select name,flatten(num_list) from `Jsn_Arry100.json`;
> Query failed: SYSTEM ERROR: initialCapacity: -2147483648 (expectd: 0+)
> [2b1960d3-c9e5-43cc-926e-783257cc1a0a on centos-04.qa.lab:31010]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
> There are 99,999 integer type elements in the input array.
> {code}
> 0: jdbc:drill:> select repeated_count(tmp.num_list) from `Jsn_Arry100.json`
> tmp;
> ++
> | EXPR$0 |
> ++
> | 9 |
> ++
> 1 row selected (0.206 seconds)
> {code}
> The below query does NOT return all the 99,999 array elements. Instead query
> returns incomplete/incorrect results.
> {code}
> 0: jdbc:drill:> select tmp.num_list from `Jsn_Arry100.json` tmp;
> ++
> | num_list |
> ++
> |
> [13729690148580628,33968383451250544,19729687836805948,10887002260554076,59060271975938184,8770403528608,73861468909987168,88448989981158368,57022772257593232,39886649400114208,59634364188801728,49220606544154264,14668098707176940,1389807151115602,68917737889186128,63305048453386056,65444797852007920,45819687647405048,2572319061962803,30445371906667328,40923257482,63616924473446912,71267711965641544,39123983528649880,33710976622262344,77269001875184320,21285915577966972,79158399148342640,59927799708140928,86792628837467632,42093378633089096,90092572909620640,27822481748467540,72874902594517600,4613424573716378,30348741516686960,15384400403234324,11312915166709258,67842306780001720,63536034928852224,34064758786460920,26742651581265676,69283348697630136,21337762946874492,33408483778102284,48525199800724472,17366398171254334,78156187420036768,55683717108215368,18931739169089156,53749386072208016,75716769953459472,70124914126143752,59670587242776496,51687272393733984,56590991314575,27798845713791992,57060186084971832,80286905552877744,11576390595076536,67263019646709888,62231475148843856,38916556483991208,56870539861336200,13820727892494552,43440054512663296,43294405699266032,22942812764355256,36368231331952648,52243742256792032,48655336740833488,87161415891865104,74521440214901872,23963586190891468,86994250559679456,64235294682694968,89237837009514944,27981168913939540,86292939130238320,9803308891945780,67756129441807768,47956437308413040,80258260743958512,33828778916469536,8419255582699858,74560162108011744,38543450292892984,21415391273461424,31658676421021728,10459153047723704,73185429768682384,2722949752940800,47317026756664832,54654463675350704,26408396249642988,43938679869946224,56284724555406552,71685791015933536,4600112644422,68794495595243400,4132552956335268,34688634621761076,35712207345268316,60213985727177096,5309212305048668,23619206841198624,64825327846779600,57007947199911488,47136678928834984,9122467237416458,40980849927903520,20914596281235304,77253379050572112,80560013812121728,46022174419866912,22101913922421504,4767879560244378,7295985537104415,33463848115973120,21159496087635528,7209644495944438,8339341099391089,56466941472321008,49199375007197008,19176844581370920,87713551163634272,68410140933429768,22463584602000640,31007049671139340,88991676818494464,86018450036815872,68296039329719152,40855740519055456,49077682665580104,8114179710795960,19904226756293724,38777905573998560,87116624775839824,64713191586087936,23526229712701268,6299956558568,61842195984909040,20542838487485340,64036764083509024,1241102073337856,2271939416579819,40485492208390352,32715355572929904,72573056371850208,79275623956295168,63005955205671488,80329641439025648,50636113571403528,84640203909310624,58152135741332672,76874210847790576,45638822712398088,14793955144036874,87502976063529168,58807684142910336,8542
[jira] [Commented] (DRILL-2851) Memory LEAK - FLATTEN function fails when input array has 99,999 integer type elements
[
https://issues.apache.org/jira/browse/DRILL-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590333#comment-14590333
]
Hanifi Gunes commented on DRILL-2851:
-
[~mehant] please review
> Memory LEAK - FLATTEN function fails when input array has 99,999 integer type
> elements
> --
>
> Key: DRILL-2851
> URL: https://issues.apache.org/jira/browse/DRILL-2851
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 0.9.0
> Environment: 64e3ec52b93e9331aa5179e040eca19afece8317 | DRILL-2611:
> value vectors should report valid value count | 16.04.2015 @ 13:53:34 EDT
>Reporter: Khurram Faraaz
>Assignee: Mehant Baid
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: Jsn_Arry100.json
>
>
> FLATTEN function does not return results when input array has 99,999 elements
> of type integer. Test was run on 4 node cluster on CentOS.
> Looks like there is a memory leak somewhere because I see this message in the
> stack trace. "Failure while closing accountor".
> {code}
> 0: jdbc:drill:> select name,flatten(num_list) from `Jsn_Arry100.json`;
> Query failed: SYSTEM ERROR: initialCapacity: -2147483648 (expectd: 0+)
> [2b1960d3-c9e5-43cc-926e-783257cc1a0a on centos-04.qa.lab:31010]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
> There are 99,999 integer type elements in the input array.
> {code}
> 0: jdbc:drill:> select repeated_count(tmp.num_list) from `Jsn_Arry100.json`
> tmp;
> ++
> | EXPR$0 |
> ++
> | 9 |
> ++
> 1 row selected (0.206 seconds)
> {code}
> The below query does NOT return all the 99,999 array elements. Instead query
> returns incomplete/incorrect results.
> {code}
> 0: jdbc:drill:> select tmp.num_list from `Jsn_Arry100.json` tmp;
> ++
> | num_list |
> ++
> |
> [13729690148580628,33968383451250544,19729687836805948,10887002260554076,59060271975938184,8770403528608,73861468909987168,88448989981158368,57022772257593232,39886649400114208,59634364188801728,49220606544154264,14668098707176940,1389807151115602,68917737889186128,63305048453386056,65444797852007920,45819687647405048,2572319061962803,30445371906667328,40923257482,63616924473446912,71267711965641544,39123983528649880,33710976622262344,77269001875184320,21285915577966972,79158399148342640,59927799708140928,86792628837467632,42093378633089096,90092572909620640,27822481748467540,72874902594517600,4613424573716378,30348741516686960,15384400403234324,11312915166709258,67842306780001720,63536034928852224,34064758786460920,26742651581265676,69283348697630136,21337762946874492,33408483778102284,48525199800724472,17366398171254334,78156187420036768,55683717108215368,18931739169089156,53749386072208016,75716769953459472,70124914126143752,59670587242776496,51687272393733984,56590991314575,27798845713791992,57060186084971832,80286905552877744,11576390595076536,67263019646709888,62231475148843856,38916556483991208,56870539861336200,13820727892494552,43440054512663296,43294405699266032,22942812764355256,36368231331952648,52243742256792032,48655336740833488,87161415891865104,74521440214901872,23963586190891468,86994250559679456,64235294682694968,89237837009514944,27981168913939540,86292939130238320,9803308891945780,67756129441807768,47956437308413040,80258260743958512,33828778916469536,8419255582699858,74560162108011744,38543450292892984,21415391273461424,31658676421021728,10459153047723704,73185429768682384,2722949752940800,47317026756664832,54654463675350704,26408396249642988,43938679869946224,56284724555406552,71685791015933536,4600112644422,68794495595243400,4132552956335268,34688634621761076,35712207345268316,60213985727177096,5309212305048668,23619206841198624,64825327846779600,57007947199911488,47136678928834984,9122467237416458,40980849927903520,20914596281235304,77253379050572112,80560013812121728,46022174419866912,22101913922421504,4767879560244378,7295985537104415,33463848115973120,21159496087635528,7209644495944438,8339341099391089,56466941472321008,49199375007197008,19176844581370920,87713551163634272,68410140933429768,22463584602000640,31007049671139340,88991676818494464,86018450036815872,68296039329719152,40855740519055456,49077682665580104,8114179710795960,19904226756293724,38777905573998560,87116624775839824,64713191586087936,23526229712701268,6299956558568,61842195984909040,20542838487485340,64036764083509024,1241102073337856,2271939416579819,40485492208390352,32715355572929904,72573056371850208,79275623956295168,63005955205671488,80329641439025648,50636113571403528,84640203909310624,58152135741332672,76874210847790576,45638822712398088,14793955144036874,87502976
[jira] [Commented] (DRILL-745) Drill fails to read the schema of avro tables from hive when the schema is in a separate file
[ https://issues.apache.org/jira/browse/DRILL-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590332#comment-14590332 ] Jason Altekruse commented on DRILL-745: --- +1 LGTM > Drill fails to read the schema of avro tables from hive when the schema is in > a separate file > - > > Key: DRILL-745 > URL: https://issues.apache.org/jira/browse/DRILL-745 > Project: Apache Drill > Issue Type: Improvement > Components: Storage - Hive >Reporter: Rahul Challapalli >Assignee: Venki Korukanti > Fix For: 1.1.0 > > Attachments: DRILL-745-1.patch, DRILL-745-2.patch > > > Follow the below steps to reproduce the issue : > 1. hadoop fs -copyFromLocal doctors.avsc /drill/ > 2. run the hive queries from doctors.ddl > 3. From drill, the describe command fails to get the schema for > doctors_fileschema table. It gives the below information : > 0: jdbc:drill:schema=dfs> describe doctors_fileschema; > +-++-+ > | COLUMN_NAME | DATA_TYPE | IS_NULLABLE | > +-++-+ > | error_error_error_error_error_error_error | VARCHAR| NO | > | cannot_determine_schema | VARCHAR| NO | > | check | VARCHAR| NO | > | schema | VARCHAR| NO | > | url | VARCHAR| NO | > | and | VARCHAR| NO | > | literal | VARCHAR| NO | > +-++-+ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-745) Drill fails to read the schema of avro tables from hive when the schema is in a separate file
[ https://issues.apache.org/jira/browse/DRILL-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Venki Korukanti updated DRILL-745: -- Attachment: DRILL-745-2.patch v2 patch. Addressed review comments. > Drill fails to read the schema of avro tables from hive when the schema is in > a separate file > - > > Key: DRILL-745 > URL: https://issues.apache.org/jira/browse/DRILL-745 > Project: Apache Drill > Issue Type: Improvement > Components: Storage - Hive >Reporter: Rahul Challapalli >Assignee: Venki Korukanti > Fix For: 1.1.0 > > Attachments: DRILL-745-1.patch, DRILL-745-2.patch > > > Follow the below steps to reproduce the issue : > 1. hadoop fs -copyFromLocal doctors.avsc /drill/ > 2. run the hive queries from doctors.ddl > 3. From drill, the describe command fails to get the schema for > doctors_fileschema table. It gives the below information : > 0: jdbc:drill:schema=dfs> describe doctors_fileschema; > +-++-+ > | COLUMN_NAME | DATA_TYPE | IS_NULLABLE | > +-++-+ > | error_error_error_error_error_error_error | VARCHAR| NO | > | cannot_determine_schema | VARCHAR| NO | > | check | VARCHAR| NO | > | schema | VARCHAR| NO | > | url | VARCHAR| NO | > | and | VARCHAR| NO | > | literal | VARCHAR| NO | > +-++-+ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3304) improve org.apache.drill.exec.expr.TypeHelper error messages when UnsupportedOprationException is thrown
[
https://issues.apache.org/jira/browse/DRILL-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deneche A. Hakim updated DRILL-3304:
Attachment: DRILL-3304.1.patch.txt
all unit tests are passing along with functional/tpch100
For example DRILL-3293, the following error message:
{noformat}
Error: SYSTEM ERROR:
Fragment 0:0
[Error Id: 96897b46-70c0-4373-9d85-ca7501cb1479 on atsqa4-133.qa.lab:31010]
(state=,code=0)
{noformat}
will be replaced by this one:
{noformat}
Error: SYSTEM ERROR: UnsupportedOperationException: Unable to get value vector
class for minor type [NULL] and mode [OPTIONAL]
Fragment 0:0
[Error Id: 446c496e-fffd-47e3-bc9f-a02a134db9b6 on 10.250.50.54:31010]
(state=,code=0)
{noformat}
> improve org.apache.drill.exec.expr.TypeHelper error messages when
> UnsupportedOprationException is thrown
>
>
> Key: DRILL-3304
> URL: https://issues.apache.org/jira/browse/DRILL-3304
> Project: Apache Drill
> Issue Type: Improvement
> Components: Execution - Data Types
>Affects Versions: 1.0.0
>Reporter: Deneche A. Hakim
>Assignee: Deneche A. Hakim
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: DRILL-3304.1.patch.txt
>
>
> TypeHelper contains several helper methods that take as parameter a
> MajorType. When the received type is incorrect, most helper methods will
> throw an UnsupportedOperationException with an empty message.
> The purpose of this Jira is to add proper messages to the thrown exceptions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-3298) Wrong result with SUM window function and order by without partition by in the OVER clause
[
https://issues.apache.org/jira/browse/DRILL-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590186#comment-14590186
]
Aman Sinha commented on DRILL-3298:
---
Doing the singleton trait for the child of window operator will work
functionally; the only problem is it will do the entire Sort on a single
node/slice. Ideally, we would want to do a parallel local sort followed by a
SingleMergeExchange and provide the output of that into the Window operator.
> Wrong result with SUM window function and order by without partition by in
> the OVER clause
> --
>
> Key: DRILL-3298
> URL: https://issues.apache.org/jira/browse/DRILL-3298
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Deneche A. Hakim
>Priority: Critical
> Labels: window_function
> Fix For: 1.1.0
>
> Attachments: DRILL-3298.1.patch.txt, j1.tar, test.res
>
>
> This query returns incorrect result when planner.slice_target = 1
> {code}
> select
> j1.c_integer,
> sum(j1.c_integer) over w
> from j1
> window w as (order by c_integer desc)
> order by
> 1, 2;
> {code}
> Query plan with planner.slice_target = 1
> {noformat}
> 00-01 Project(c_integer=[$0], EXPR$1=[$1])
> 00-02SingleMergeExchange(sort0=[0 ASC], sort1=[1 ASC])
> 01-01 SelectionVectorRemover
> 01-02Sort(sort0=[$0], sort1=[$1], dir0=[ASC], dir1=[ASC])
> 01-03 Project(c_integer=[$0], EXPR$1=[$1])
> 01-04HashToRandomExchange(dist0=[[$0]], dist1=[[$1]])
> 02-01 UnorderedMuxExchange
> 03-01Project(c_integer=[$0], EXPR$1=[$1],
> E_X_P_R_H_A_S_H_F_I_E_L_D=[castInt(hash64AsDouble($1, hash64AsDouble($0)))])
> 03-02 Project(c_integer=[$0], EXPR$1=[CASE(>($1, 0),
> CAST($2):ANY, null)])
> 03-03Window(window#0=[window(partition {} order by [0
> DESC] range between UNBOUNDED PRECEDING and CURRENT ROW aggs [COUNT($0),
> $SUM0($0)])])
> 03-04 SelectionVectorRemover
> 03-05Sort(sort0=[$0], dir0=[DESC])
> 03-06 Scan(groupscan=[ParquetGroupScan
> [entries=[ReadEntryWithPath [path=maprfs:///drill/testdata/subqueries/j1]],
> selectionRoot=/drill/testdata/subqueries/j1, numFiles=1,
> columns=[`c_integer`]]])
> {noformat}
> Query plan with planner.slice_target = 10;
> {noformat}
> 00-01 Project(c_integer=[$0], EXPR$1=[$1])
> 00-02SelectionVectorRemover
> 00-03 Sort(sort0=[$0], sort1=[$1], dir0=[ASC], dir1=[ASC])
> 00-04Project(c_integer=[$0], EXPR$1=[CASE(>($1, 0), CAST($2):ANY,
> null)])
> 00-05 Window(window#0=[window(partition {} order by [0 DESC]
> range between UNBOUNDED PRECEDING and CURRENT ROW aggs [COUNT($0),
> $SUM0($0)])])
> 00-06SelectionVectorRemover
> 00-07 Sort(sort0=[$0], dir0=[DESC])
> 00-08Scan(groupscan=[ParquetGroupScan
> [entries=[ReadEntryWithPath [path=maprfs:///drill/testdata/subqueries/j1]],
> selectionRoot=/drill/testdata/subqueries/j1, numFiles=1,
> columns=[`c_integer`]]])
> {noformat}
> Attached:
> * table j1
> * test.res - result generated with postgres
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DRILL-3276) Broken links on Apache Drill documentation
[ https://issues.apache.org/jira/browse/DRILL-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristine Hahn resolved DRILL-3276. -- Resolution: Fixed Published fixes at last. > Broken links on Apache Drill documentation > -- > > Key: DRILL-3276 > URL: https://issues.apache.org/jira/browse/DRILL-3276 > Project: Apache Drill > Issue Type: Bug > Components: Documentation >Reporter: Andries Engelbrecht >Assignee: Kristine Hahn >Priority: Minor > > Following links result in a paige not found error > http://drill.apache.org/docs/supported-data-types-for-casting > http://drill.apache.org/docs/explicit-type-casting-maps > The links are found on this page > http://drill.apache.org/docs/data-type-conversion/#cast -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DRILL-3276) Broken links on Apache Drill documentation
[ https://issues.apache.org/jira/browse/DRILL-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristine Hahn closed DRILL-3276. > Broken links on Apache Drill documentation > -- > > Key: DRILL-3276 > URL: https://issues.apache.org/jira/browse/DRILL-3276 > Project: Apache Drill > Issue Type: Bug > Components: Documentation >Reporter: Andries Engelbrecht >Assignee: Kristine Hahn >Priority: Minor > > Following links result in a paige not found error > http://drill.apache.org/docs/supported-data-types-for-casting > http://drill.apache.org/docs/explicit-type-casting-maps > The links are found on this page > http://drill.apache.org/docs/data-type-conversion/#cast -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3304) improve org.apache.drill.exec.expr.TypeHelper error messages when UnsupportedOprationException is thrown
[ https://issues.apache.org/jira/browse/DRILL-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deneche A. Hakim updated DRILL-3304: Component/s: Execution - Data Types > improve org.apache.drill.exec.expr.TypeHelper error messages when > UnsupportedOprationException is thrown > > > Key: DRILL-3304 > URL: https://issues.apache.org/jira/browse/DRILL-3304 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Data Types >Affects Versions: 1.0.0 >Reporter: Deneche A. Hakim >Assignee: Deneche A. Hakim >Priority: Minor > Fix For: 1.1.0 > > > TypeHelper contains several helper methods that take as parameter a > MajorType. When the received type is incorrect, most helper methods will > throw an UnsupportedOperationException with an empty message. > The purpose of this Jira is to add proper messages to the thrown exceptions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3284) Document incompatibility between drill's to_date and hive's unix_timestamp
[
https://issues.apache.org/jira/browse/DRILL-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590184#comment-14590184
]
Kristine Hahn commented on DRILL-3284:
--
Docs will include the example from Steven, liked by Ted:
> On Jun 16, 2015, at 2:01, Steven wrote:
>
> There is a version of unix_timestamp that accepts a Date format pattern:
>
> select to_timestamp(1432912733), unix_timestamp(to_timestamp(1432912733),
> '-MM-dd HH:mm:ss.SSS') from `sys`.`version`;
> ++-+
> | EXPR$0 | EXPR$1|
> ++-+
> | 2015-05-29 08:18:53.0 | 1432912733 |
> ++-+
> Document incompatibility between drill's to_date and hive's unix_timestamp
> --
>
> Key: DRILL-3284
> URL: https://issues.apache.org/jira/browse/DRILL-3284
> Project: Apache Drill
> Issue Type: Bug
> Components: Documentation, Functions - Hive
>Reporter: Rahul Challapalli
>Assignee: Kristine Hahn
>
> The below query from drill produces wrong results because unix_timestamp
> (function from hive) returns the value in seconds while to_date treats its
> input in milliseconds.
> {code}
> select to_date(unix_timestamp('1998-05-06', '-MM-dd')) from dummy limit 1;
> +-+
> | EXPR$0|
> +-+
> | 1970-01-11 |
> +-+
> {code}
> In order to make this work we should use the below query
> {code}
> select to_date(unix_timestamp('1998-05-06', '-MM-dd')*1000) from dummy
> limit 1;
> +-+
> | EXPR$0|
> +-+
> | 1998-05-06 |
> +-+
> {code}
> If this is not a bug on drill's side, we should atleast document this
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DRILL-2137) ResultsSetMetaData.getColumnName() returns "none" (rather than right class name)
[
https://issues.apache.org/jira/browse/DRILL-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) closed DRILL-2137.
-
Resolution: Fixed
Closing because superseded by DRILL-3151.
> ResultsSetMetaData.getColumnName() returns "none" (rather than right class
> name)
>
>
> Key: DRILL-2137
> URL: https://issues.apache.org/jira/browse/DRILL-2137
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: 1.1.0
>
>
> The implementation of {{java.sql.ResultsSetMetaData.getColumnName()}} returns
> "none" rather than returning the correct class name ("the class ... that
> would be used by the method {{ResultSet.getObject}} to retrieve the value in
> the specified column").
> DrillColumnMetaData.updateColumnMetaData(...) has the hard-coded "none" value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3151) ResultMetaData not as specified by JDBC (null/dummy value, not ""/etc.)
[
https://issues.apache.org/jira/browse/DRILL-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-3151:
--
Summary: ResultMetaData not as specified by JDBC (null/dummy value, not
""/etc.) (was: ResultMetaData not as specified by JDBC ("" or dummy value
instead of ))
> ResultMetaData not as specified by JDBC (null/dummy value, not ""/etc.)
> ---
>
> Key: DRILL-3151
> URL: https://issues.apache.org/jira/browse/DRILL-3151
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: 1.1.0
>
>
> In Drill's JDBC driver, some ResultSetMetaData methods don't return what JDBC
> specifies they should return.
> Some cases:
> {{getTableName(int)}}:
> - (JDBC says: {{table name or "" if not applicable}})
> - Drill returns {{null}} (instead of empty string or table name)
> - (Drill indicates "not applicable" even when from named table, e.g., for
> "{{SELECT * FROM INFORMATION_SCHEMA.CATALOGS}}".)
> {{getSchemaName(int)}}:
> - (JDBC says: {{schema name or "" if not applicable}})
> - Drill returns "{{\-\-UNKNOWN--}}" (instead of empty string or schema name)
> - (Drill indicates "not applicable" even when from named table, e.g., for
> "{{SELECT * FROM INFORMATION_SCHEMA.CATALOGS}}".)
> {{getCatalogName(int)}}:
> - (JDBC says: {{the name of the catalog for the table in which the given
> column appears or "" if not applicable}})
> - Drill returns "{{\-\-UNKNOWN--}}" (instead of empty string or catalog name)
> - (Drill indicates "not applicable" even when from named table, e.g., for
> "{{SELECT * FROM INFORMATION_SCHEMA.CATALOGS}}".)
> {{isSearchable(int)}}:
> - (JDBC says: {{Indicates whether the designated column can be used in a
> where clause.}})
> - Drill returns {{false}}.
> {{getColumnClassName(int}}:
> - (JDBC says: {{the fully-qualified name of the class in the Java programming
> language that would be used by the method ResultSet.getObject to retrieve the
> value in the specified column. This is the class name used for custom
> mapping.}})
> - Drill returns "{{none}}" (instead of the correct class name).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
