[jira] [Commented] (DRILL-7673) View set query fails with NPE for non-existing option
[
https://issues.apache.org/jira/browse/DRILL-7673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071258#comment-17071258
]
ASF GitHub Bot commented on DRILL-7673:
---
asfgit commented on pull request #2043: DRILL-7673: View set query fails with
NPE for non-existing option
URL: https://github.com/apache/drill/pull/2043
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> View set query fails with NPE for non-existing option
> -
>
> Key: DRILL-7673
> URL: https://issues.apache.org/jira/browse/DRILL-7673
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.17.0
>Reporter: Vova Vysotskyi
>Assignee: Vova Vysotskyi
>Priority: Minor
> Labels: ready-to-commit
> Fix For: 1.18.0
>
>
> The following query fails with NPE:
> {code:sql}
> set `non-existing option`
> {code}
> Stack trace:
> {noformat}
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.drill.exec.planner.sql.handlers.SetOptionHandler.getPlan(SetOptionHandler.java:66)
> at
> org.apache.drill.exec.planner.sql.DrillSqlWorker.getQueryPlan(DrillSqlWorker.java:283)
> at
> org.apache.drill.exec.planner.sql.DrillSqlWorker.getPhysicalPlan(DrillSqlWorker.java:163)
> at
> org.apache.drill.exec.planner.sql.DrillSqlWorker.convertPlan(DrillSqlWorker.java:140)
> at
> org.apache.drill.exec.planner.sql.DrillSqlWorker.getPlan(DrillSqlWorker.java:93)
> at org.apache.drill.exec.work.foreman.Foreman.runSQL(Foreman.java:592)
> at org.apache.drill.exec.work.foreman.Foreman.run(Foreman.java:277)
> ... 3 common frames omitted
> {noformat}
> Also, the result of the command returns option name with the same case as it
> was specified in the query:
> {noformat}
> set `metastore.ENABLED`;
> +---+---+
> | name| value |
> +---+---+
> | metastore.ENABLED | false |
> +---+---+
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DRILL-6604) Upgrade Drill Hive client to Hive3.1 version
[
https://issues.apache.org/jira/browse/DRILL-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071255#comment-17071255
]
ASF GitHub Bot commented on DRILL-6604:
---
asfgit commented on pull request #2038: DRILL-6604: Upgrade Drill Hive client
to Hive3.1 version
URL: https://github.com/apache/drill/pull/2038
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Upgrade Drill Hive client to Hive3.1 version
>
>
> Key: DRILL-6604
> URL: https://issues.apache.org/jira/browse/DRILL-6604
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.14.0
>Reporter: Vitalii Diravka
>Assignee: Vova Vysotskyi
>Priority: Major
> Labels: ready-to-commit
> Fix For: 1.18.0
>
>
> Recently the Hive3.1 version is released.
> 3.1 versions of {{hive-exec}} and {{hive-metastore}} (main Drill Hive client
> libraries) are the last available artifacts in maven repo for now:
> [https://mvnrepository.com/artifact/org.apache.hive/hive-exec/3.1.0]
> [https://mvnrepository.com/artifact/org.apache.hive/hive-metastore/3.1.0]
> It is necessary to investigate what impact of update onto the newer major
> Hive client version.
> The initial conflicts after changing the {{hive.version}} in Drill root pom
> file from 2.3.2 to 3.1.0 are:
> {code}
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/vitalii/IdeaProjects/drill-fork/contrib/storage-hive/core/src/main/java/org/apache/drill/exec/store/hive/HiveUtilities.java:[58,39]
> error: cannot find symbol
> [ERROR] symbol: class MetaStoreUtils
> location: package org.apache.hadoop.hive.metastore
> /home/vitalii/IdeaProjects/drill-fork/contrib/storage-hive/core/src/main/java/org/apache/drill/exec/store/hive/HiveMetadataProvider.java:[34,39]
> error: cannot find symbol
> [INFO] 2 errors
> {code}
> {code}
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/vitalii/IdeaProjects/drill-fork/contrib/storage-hive/core/src/main/java/org/apache/drill/exec/store/hive/HiveUtilities.java:[575,15]
> error: cannot find symbol
> [ERROR] symbol: method setTransactionalTableScan(JobConf,boolean)
> location: class AcidUtils
> /home/vitalii/IdeaProjects/drill-fork/contrib/storage-hive/core/src/main/java/org/apache/drill/exec/store/hive/HiveFieldConverter.java:[216,92]
> error: incompatible types: org.apache.hadoop.hive.common.type.Timestamp
> cannot be converted to java.sql.Timestamp
> [ERROR]
> /home/vitalii/IdeaProjects/drill-fork/contrib/storage-hive/core/src/main/java/org/apache/drill/exec/store/hive/HiveFieldConverter.java:[225,82]
> error: incompatible types: org.apache.hadoop.hive.common.type.Date cannot be
> converted to java.sql.Date
> [ERROR]
> /home/vitalii/IdeaProjects/drill-fork/contrib/storage-hive/core/src/main/java/org/apache/drill/exec/store/hive/DrillHiveMetaStoreClient.java:[100,17]
> error: cannot find symbol
> [ERROR] symbol: method setTokenStr(UserGroupInformation,String,String)
> location: class Utils
> /home/vitalii/IdeaProjects/drill-fork/contrib/storage-hive/core/target/generated-sources/org/apache/drill/exec/expr/fn/impl/hive/DrillTimeStampTimestampObjectInspector.java:[29,16]
> error: Required is not abstract and does not override abstract method
> getPrimitiveJavaObject(Object) in TimestampObjectInspector
> [ERROR]
> /home/vitalii/IdeaProjects/drill-fork/contrib/storage-hive/core/target/generated-sources/org/apache/drill/exec/expr/fn/impl/hive/DrillTimeStampTimestampObjectInspector.java:[35,30]
> error: getPrimitiveJavaObject(Object) in Required cannot implement
> getPrimitiveJavaObject(Object) in TimestampObjectInspector
> [ERROR] return type java.sql.Timestamp is not compatible with
> org.apache.hadoop.hive.common.type.Timestamp
> /home/vitalii/IdeaProjects/drill-fork/contrib/storage-hive/core/target/generated-sources/org/apache/drill/exec/expr/fn/impl/hive/DrillTimeStampTimestampObjectInspector.java:[44,29]
> error: getPrimitiveWritableObject(Object) in Required cannot implement
> getPrimitiveWritableObject(Object) in TimestampObjectInspector
> [ERROR] return type TimestampWritable is not compatible with
> TimestampWritableV2
> /home/vitalii/IdeaProjects/drill-fork/contrib/storage-hive/core/target/generated-sources/org/apache/drill/exec/expr/fn/impl/hive/DrillTimeStampTimestampObjectInspector.java:[54,16]
> error: Optional is not abstract and does not override abstract method
>
[jira] [Commented] (DRILL-7672) Make metadata type required when reading from / writing into Drill Metastore
[ https://issues.apache.org/jira/browse/DRILL-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071257#comment-17071257 ] ASF GitHub Bot commented on DRILL-7672: --- asfgit commented on pull request #2042: DRILL-7672: Make metadata type required when reading from / writing into Drill Metastore URL: https://github.com/apache/drill/pull/2042 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Make metadata type required when reading from / writing into Drill Metastore > > > Key: DRILL-7672 > URL: https://issues.apache.org/jira/browse/DRILL-7672 > Project: Apache Drill > Issue Type: Improvement >Affects Versions: 1.17.0 >Reporter: Arina Ielchiieva >Assignee: Arina Ielchiieva >Priority: Major > Labels: ready-to-commit > Fix For: 1.18.0 > > > Metastore consists of components: TABLES, VIEWS etc (so far only TABLES are > implemented). Each component metadata can have types. For examples, TABLES > metadata can be of the following types: TABLE, SEGMENT, FILE, ROW_GROUP, > PARTITION. > During initial Metastore implementation when reading from / writing into > Metastore, metadata type was indicated in filter expressions. > For Iceberg Metastore where all data is stored in files this was not this > critical, basically when information is retrieved about the table, table > folder is queried. > For other Metastore implementations knowing metadata type can be more > critical. For example, RDBMS Metastore would store TABLES metadata in > different tables thus knowing which table to query would improve performance > rather than trying to query all tables. > Of course, we could traverse query filter and look for the hints which > metadata type is needed but it is much better to know required metadata type > beforehand without any extra logic. > Taking into account that Metastore metadata is queried only in Drill code, > developer knows beforehand what he needs to get / update / delete. > This Jira aims to make metadata type required when reading from / writing > into Drill Metastore. This change does not have any affect on the users, just > internal code refactoring. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DRILL-7641) Convert Excel Reader to Use Streaming Reader
[ https://issues.apache.org/jira/browse/DRILL-7641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071256#comment-17071256 ] ASF GitHub Bot commented on DRILL-7641: --- asfgit commented on pull request #2024: DRILL-7641: Convert Excel Reader to use Streaming Reader URL: https://github.com/apache/drill/pull/2024 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Convert Excel Reader to Use Streaming Reader > > > Key: DRILL-7641 > URL: https://issues.apache.org/jira/browse/DRILL-7641 > Project: Apache Drill > Issue Type: Improvement > Components: Storage - Text CSV >Affects Versions: 1.17.0 >Reporter: Charles Givre >Assignee: Charles Givre >Priority: Major > Labels: ready-to-commit > Fix For: 1.18.0 > > > The current implementation of the Excel reader uses the Apache POI reader, > which uses excessive amounts of memory. As a result, attempting to read large > Excel files will cause out of memory errors. > This PR converts the format plugin to use a streaming reader, based still on > the POI library. The documentation for the streaming reader can be found > here. [1] > All unit tests pass and I tested the plugin with some large Excel files on my > computer. > [1]: [https://github.com/pjfanning/excel-streaming-reader] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DRILL-7668) Allow Time Bucket Function to Accept Floats and Timestamps
[
https://issues.apache.org/jira/browse/DRILL-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071216#comment-17071216
]
ASF GitHub Bot commented on DRILL-7668:
---
vvysotskyi commented on issue #2040: DRILL-7668: Allow Time Bucket Function to
Accept Floats and Timestamps
URL: https://github.com/apache/drill/pull/2040#issuecomment-606196720
@cgivre, this pull request introduces unit tests failure:
```
[ERROR]
org.apache.drill.exec.udfs.TestTimeBucketFunction.testTimeBucketTimestamp Time
elapsed: 2.584 s <<< ERROR!
java.lang.Exception:
at position 0 column '`high`' mismatched values, expected:
2020-03-27T01:30(LocalDateTime) but received 2020-03-26T18:30(LocalDateTime)
Expected Records near verification failure:
Record Number: 0 { `high` : 2020-03-27T01:30, }
Actual Records near verification failure:
Record Number: 0 { `high` : 2020-03-26T18:30, }
For query: SELECT time_bucket(CAST(1585272833845 AS TIMESTAMP), 30) AS
high FROM (values(1))
at
org.apache.drill.exec.udfs.TestTimeBucketFunction.testTimeBucketTimestamp(TestTimeBucketFunction.java:116)
Caused by: java.lang.Exception:
at position 0 column '`high`' mismatched values, expected:
2020-03-27T01:30(LocalDateTime) but received 2020-03-26T18:30(LocalDateTime)
Expected Records near verification failure:
Record Number: 0 { `high` : 2020-03-27T01:30, }
Actual Records near verification failure:
Record Number: 0 { `high` : 2020-03-26T18:30, }
at
org.apache.drill.exec.udfs.TestTimeBucketFunction.testTimeBucketTimestamp(TestTimeBucketFunction.java:116)
Caused by: java.lang.Exception: at position 0 column '`high`' mismatched
values, expected: 2020-03-27T01:30(LocalDateTime) but received
2020-03-26T18:30(LocalDateTime)
at
org.apache.drill.exec.udfs.TestTimeBucketFunction.testTimeBucketTimestamp(TestTimeBucketFunction.java:116)
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Allow Time Bucket Function to Accept Floats and Timestamps
> --
>
> Key: DRILL-7668
> URL: https://issues.apache.org/jira/browse/DRILL-7668
> Project: Apache Drill
> Issue Type: Improvement
> Components: Functions - Drill
>Affects Versions: 1.18.0
>Reporter: Charles Givre
>Assignee: Charles Givre
>Priority: Minor
> Labels: ready-to-commit
> Fix For: 1.18.0
>
>
> Drill has a function `time_bucket()` which facilitates time series analysis.
> This PR extends this function to accept `FLOAT8` and `TIMESTAMPS` as input.
> Floats are typically not used for timestamps, however in the event that the
> data is coming from imperfect files, the numbers may be read as floats and
> hence require casting in queries. This PR makes this easier.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DRILL-6975) TO_CHAR does not seems work well depends on LOCALE
[
https://issues.apache.org/jira/browse/DRILL-6975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
benj updated DRILL-6975:
Affects Version/s: 1.17.0
> TO_CHAR does not seems work well depends on LOCALE
> --
>
> Key: DRILL-6975
> URL: https://issues.apache.org/jira/browse/DRILL-6975
> Project: Apache Drill
> Issue Type: Bug
> Components: Functions - Drill
>Affects Versions: 1.14.0, 1.15.0, 1.16.0, 1.17.0
>Reporter: benj
>Priority: Major
>
> Strange results from TO_CHAR function when using different LOCALE.
> {code:java}
> SELECT TO_CHAR((CAST('2008-2-23' AS DATE)), '-MMM-dd') FROM (VALUES(1));
> 2008-Feb-23 (in documentation (en_US.UTF-8))
> 2008-févr.-2 (fr_FR.UTF-8)
> {code}
> surprisingly by adding a space ('-MMM-dd ') (or any character) at the end
> of the format the result becomes correct (so there is no problem when format
> a timestamp with ' MMM dd HH:mm:ss')
> {code:java}
> SELECT TO_CHAR(1256.789383, '#,###.###') FROM (VALUES(1));
> 1,256.789 (in documentation (en_US.UTF-8))
> 1 256,78 (fr_FR.UTF-8)
> {code}
> Even worse results can be achieved
> {code:java}
> SELECT TO_CHAR(12567,'#,###.###');
> 12,567 (en_US.UTF-8)
> 12 56 (fr_FR.UTF-8)
> {code}
> Again, with the add of a space/char at the end we get a better result.
> I don't have tested all the locale, but for the last example, the result is
> right with de_DE.UTF-8 : 12.567
> The situation is identical in 1.14
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DRILL-7677) NPE in getStringFromVarCharHolder(NullableVarCharHolder)
[
https://issues.apache.org/jira/browse/DRILL-7677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070949#comment-17070949
]
Charles Givre commented on DRILL-7677:
--
[~nielsbasjes]
I think you've uncovered a gripe of mine with how Drill handles UDFs that have
a complex field as output. A normal UDF you can specify the null handling and
then you can safely assume that the data the function receives is not null.
However, in the case of UDFs which output complex fields, it is necessary to
have two versions: one that has a non-nullable holder as input, that actually
returns the correct output and a second that has a nullable holder as input and
returns an empty list or map as output.
In any event, there are unit tests for this function [1] that include tests for
null values.
[1]:
https://github.com/apache/drill/blob/master/contrib/udfs/src/test/java/org/apache/drill/exec/udfs/TestUserAgentFunctions.java
> NPE in getStringFromVarCharHolder(NullableVarCharHolder)
> -
>
> Key: DRILL-7677
> URL: https://issues.apache.org/jira/browse/DRILL-7677
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Niels Basjes
>Priority: Major
>
> Assume you have a function ([like this
> one|https://github.com/apache/drill/blob/master/contrib/udfs/src/main/java/org/apache/drill/exec/udfs/UserAgentFunctions.java#L110])
> that has
> {code:java}
> @Param
> NullableVarCharHolder input;
> {code}
> and in the {code:java}eval(){code} function you do
> {code:java}String inputString =
> org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getStringFromVarCharHolder(input);{code}
> When this function is called with the input actually being null the 'input'
> parameter is an instance of NullableVarCharHolder where isSet is 0 and buffer
> is null.
> The buffer being null causes an NPE in the call to
> getStringFromVarCharHolder(NullableVarCharHolder)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DRILL-6319) Format Plugin for ESRI Shape Files
[ https://issues.apache.org/jira/browse/DRILL-6319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Givre resolved DRILL-6319. -- Fix Version/s: 1.16.0 Resolution: Resolved > Format Plugin for ESRI Shape Files > -- > > Key: DRILL-6319 > URL: https://issues.apache.org/jira/browse/DRILL-6319 > Project: Apache Drill > Issue Type: Improvement >Affects Versions: Future >Reporter: Charles Givre >Assignee: Chris Sandison >Priority: Major > Fix For: 1.16.0 > > > As Drill has incorporated various GIS functionality, it would be very useful > for Drill to be able to natively read ESRI shape files so that these polygons > can be incorporated into queries with GIS functionality. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (DRILL-6319) Format Plugin for ESRI Shape Files
[ https://issues.apache.org/jira/browse/DRILL-6319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Givre closed DRILL-6319. Assignee: Charles Givre (was: Chris Sandison) > Format Plugin for ESRI Shape Files > -- > > Key: DRILL-6319 > URL: https://issues.apache.org/jira/browse/DRILL-6319 > Project: Apache Drill > Issue Type: Improvement >Affects Versions: Future >Reporter: Charles Givre >Assignee: Charles Givre >Priority: Major > Fix For: 1.16.0 > > > As Drill has incorporated various GIS functionality, it would be very useful > for Drill to be able to natively read ESRI shape files so that these polygons > can be incorporated into queries with GIS functionality. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (DRILL-3951) Lexical Errors in ODBC Queries
[
https://issues.apache.org/jira/browse/DRILL-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Givre closed DRILL-3951.
> Lexical Errors in ODBC Queries
> --
>
> Key: DRILL-3951
> URL: https://issues.apache.org/jira/browse/DRILL-3951
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - ODBC
>Affects Versions: 1.1.0, 1.2.0
> Environment: Mac OS 10.11, Apache Drill v. 1.2, Python 3.4,
>Reporter: Charles Givre
>Priority: Major
>
> I followed the instructions to install the latest version of Apache Drill,
> and the Mapr ODBC drivers, but when I attempt to query a data source via
> ODBC, I get the following errors:
> Error: ('HY000', '[HY000] [MapR][Drill] (1040) Drill failed to execute the
> query: `\n[30027]Query execution error. Details:[ \nPARSE
> ERROR: Lexical error at line 1, column 1. Encountered: "\\ufffd" (65533),
> after : ""\n\n\n[Error Id: 8e1f4049-f3e9-477f-9e3f-5df62c (1040)
> (SQLExecDirectW)')
> Here is the code which generates the errors:
> import pyodbc
> import pandas as pd
> MY_DSN =
> "DRIVER=/opt/mapr/drillodbc/lib/universal/libmaprdrillodbc.dylib;Host=localhost;Port=31010;ConnectionType=Direct;Catalog=Drill;Schema=mfs.views;AuthenticationType=No
> Authentication"
> conn = pyodbc.connect(MY_DSN, autocommit=True)
> cursor = conn.cursor()
> employee_query = "SELECT * FROM dfs.`employee.json`"
> data = pd.read_sql( employee_query, conn )
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (DRILL-4955) Log Parser for Drill
[
https://issues.apache.org/jira/browse/DRILL-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Givre closed DRILL-4955.
> Log Parser for Drill
>
>
> Key: DRILL-4955
> URL: https://issues.apache.org/jira/browse/DRILL-4955
> Project: Apache Drill
> Issue Type: New Feature
> Components: Storage - Text CSV
>Affects Versions: 1.9.0
>Reporter: Charles Givre
>Priority: Major
> Labels: features
> Fix For: Future
>
>
> I've been experimenting with a generic log parser for Drill. The basic
> concept is that if you wanted Drill to ingest log files such as this MySQL
> log:
> {code}
> 070823 21:00:32 1 Connect root@localhost on test1
> 070823 21:00:48 1 Query show tables
> 070823 21:00:56 1 Query select * from category
> 070917 16:29:01 21 Query select * from location
> 070917 16:29:12 21 Query select * from location where id = 1 LIMIT
> 1
> {code}
> You probably could do it with the various string manipulation methods such as
> split, substring etc. but you'd end up with some ugly and very complex
> queries.
> The extension I've built allows you to supply Drill with a regex for the
> formatting and a list of fields as shown below.
> {code}
> "log": {
> "type": "log",
> "extensions": [
> "log"
> ],
> "fieldNames": [
> "date",
> "time",
> "pid",
> "action",
> "query"
> ],
> "pattern":
> "(\\d{6})\\s(\\d{2}:\\d{2}:\\d{2})\\s+(\\d+)\\s(\\w+)\\s+(.+)"
> }
> {code}
> You can then query this log files in this format in Drill. I'd like to
> submit this for inclusion in Drill if there is interest.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DRILL-4955) Log Parser for Drill
[
https://issues.apache.org/jira/browse/DRILL-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Givre resolved DRILL-4955.
--
Resolution: Resolved
> Log Parser for Drill
>
>
> Key: DRILL-4955
> URL: https://issues.apache.org/jira/browse/DRILL-4955
> Project: Apache Drill
> Issue Type: New Feature
> Components: Storage - Text CSV
>Affects Versions: 1.9.0
>Reporter: Charles Givre
>Priority: Major
> Labels: features
> Fix For: Future
>
>
> I've been experimenting with a generic log parser for Drill. The basic
> concept is that if you wanted Drill to ingest log files such as this MySQL
> log:
> {code}
> 070823 21:00:32 1 Connect root@localhost on test1
> 070823 21:00:48 1 Query show tables
> 070823 21:00:56 1 Query select * from category
> 070917 16:29:01 21 Query select * from location
> 070917 16:29:12 21 Query select * from location where id = 1 LIMIT
> 1
> {code}
> You probably could do it with the various string manipulation methods such as
> split, substring etc. but you'd end up with some ugly and very complex
> queries.
> The extension I've built allows you to supply Drill with a regex for the
> formatting and a list of fields as shown below.
> {code}
> "log": {
> "type": "log",
> "extensions": [
> "log"
> ],
> "fieldNames": [
> "date",
> "time",
> "pid",
> "action",
> "query"
> ],
> "pattern":
> "(\\d{6})\\s(\\d{2}:\\d{2}:\\d{2})\\s+(\\d+)\\s(\\w+)\\s+(.+)"
> }
> {code}
> You can then query this log files in this format in Drill. I'd like to
> submit this for inclusion in Drill if there is interest.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DRILL-7677) NPE in getStringFromVarCharHolder(NullableVarCharHolder)
[
https://issues.apache.org/jira/browse/DRILL-7677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070969#comment-17070969
]
Vova Vysotskyi commented on DRILL-7677:
---
Actually, such methods that accept holders should be removed from UDFs code.
Please see DRILL-6075 for details.
> NPE in getStringFromVarCharHolder(NullableVarCharHolder)
> -
>
> Key: DRILL-7677
> URL: https://issues.apache.org/jira/browse/DRILL-7677
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Niels Basjes
>Priority: Major
>
> Assume you have a function ([like this
> one|https://github.com/apache/drill/blob/master/contrib/udfs/src/main/java/org/apache/drill/exec/udfs/UserAgentFunctions.java#L110])
> that has
> {code:java}
> @Param
> NullableVarCharHolder input;
> {code}
> and in the {code:java}eval(){code} function you do
> {code:java}String inputString =
> org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getStringFromVarCharHolder(input);{code}
> When this function is called with the input actually being null the 'input'
> parameter is an instance of NullableVarCharHolder where isSet is 0 and buffer
> is null.
> The buffer being null causes an NPE in the call to
> getStringFromVarCharHolder(NullableVarCharHolder)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DRILL-3951) Lexical Errors in ODBC Queries
[
https://issues.apache.org/jira/browse/DRILL-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Givre resolved DRILL-3951.
--
Resolution: Resolved
> Lexical Errors in ODBC Queries
> --
>
> Key: DRILL-3951
> URL: https://issues.apache.org/jira/browse/DRILL-3951
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - ODBC
>Affects Versions: 1.1.0, 1.2.0
> Environment: Mac OS 10.11, Apache Drill v. 1.2, Python 3.4,
>Reporter: Charles Givre
>Priority: Major
>
> I followed the instructions to install the latest version of Apache Drill,
> and the Mapr ODBC drivers, but when I attempt to query a data source via
> ODBC, I get the following errors:
> Error: ('HY000', '[HY000] [MapR][Drill] (1040) Drill failed to execute the
> query: `\n[30027]Query execution error. Details:[ \nPARSE
> ERROR: Lexical error at line 1, column 1. Encountered: "\\ufffd" (65533),
> after : ""\n\n\n[Error Id: 8e1f4049-f3e9-477f-9e3f-5df62c (1040)
> (SQLExecDirectW)')
> Here is the code which generates the errors:
> import pyodbc
> import pandas as pd
> MY_DSN =
> "DRIVER=/opt/mapr/drillodbc/lib/universal/libmaprdrillodbc.dylib;Host=localhost;Port=31010;ConnectionType=Direct;Catalog=Drill;Schema=mfs.views;AuthenticationType=No
> Authentication"
> conn = pyodbc.connect(MY_DSN, autocommit=True)
> cursor = conn.cursor()
> employee_query = "SELECT * FROM dfs.`employee.json`"
> data = pd.read_sql( employee_query, conn )
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DRILL-7677) NPE in getStringFromVarCharHolder(NullableVarCharHolder)
[
https://issues.apache.org/jira/browse/DRILL-7677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070968#comment-17070968
]
Charles Givre commented on DRILL-7677:
--
[~nielsbasjes]
What you're saying makes sense. The bigger issue is that Drill needs a way for
functions with complex return values to return an empty map or list. If you do
that, then you don't have to worry about null handling in the function body
because if the input(s) are null, then the function automatically will return
an empty list or map. I realized I actually created a Jira issue for this.
See https://issues.apache.org/jira/browse/DRILL-7366.
> NPE in getStringFromVarCharHolder(NullableVarCharHolder)
> -
>
> Key: DRILL-7677
> URL: https://issues.apache.org/jira/browse/DRILL-7677
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Niels Basjes
>Priority: Major
>
> Assume you have a function ([like this
> one|https://github.com/apache/drill/blob/master/contrib/udfs/src/main/java/org/apache/drill/exec/udfs/UserAgentFunctions.java#L110])
> that has
> {code:java}
> @Param
> NullableVarCharHolder input;
> {code}
> and in the {code:java}eval(){code} function you do
> {code:java}String inputString =
> org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getStringFromVarCharHolder(input);{code}
> When this function is called with the input actually being null the 'input'
> parameter is an instance of NullableVarCharHolder where isSet is 0 and buffer
> is null.
> The buffer being null causes an NPE in the call to
> getStringFromVarCharHolder(NullableVarCharHolder)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DRILL-7423) Create More Efficient Way to Read Excel Cells
[ https://issues.apache.org/jira/browse/DRILL-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Givre resolved DRILL-7423. -- Resolution: Resolved > Create More Efficient Way to Read Excel Cells > - > > Key: DRILL-7423 > URL: https://issues.apache.org/jira/browse/DRILL-7423 > Project: Apache Drill > Issue Type: Improvement >Affects Versions: 1.18.0 >Reporter: Charles Givre >Priority: Major > > The Excel format plugin reads cells but there are ways to make the reading > process more efficient. Since the schema of an Excel file is not known in > advance, Drill must read the first row of data in order to extract the > schema. > It is actually a bit more complex. To read the schema, Drill must first read > the header rows and convert them all into Strings. This gets us the header > names if present. > Drill cannot create writers until it actually reads the first row of data > where it will determine the data types. This creates an inefficiency in that > when Drill is writing the columns, it has to do a hash lookup for each > column. Since the columns are in a fixed order, it may be possible to store > the writers in an array and gain some efficiency there. > Also at present, if the columns are heterogenous, Drill requires the user to > use allTextMode to query the data. It would be nice if Drill could query the > data w/o having to set that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DRILL-7677) NPE in getStringFromVarCharHolder(NullableVarCharHolder)
[
https://issues.apache.org/jira/browse/DRILL-7677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070944#comment-17070944
]
Vova Vysotskyi commented on DRILL-7677:
---
[~nielsbasjes], NPE which you have described shouldn't happen since this
function contains a check {{input.isSet == 0}} above the line you have pointed
which will return from the method.
> NPE in getStringFromVarCharHolder(NullableVarCharHolder)
> -
>
> Key: DRILL-7677
> URL: https://issues.apache.org/jira/browse/DRILL-7677
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Niels Basjes
>Priority: Major
>
> Assume you have a function ([like this
> one|https://github.com/apache/drill/blob/master/contrib/udfs/src/main/java/org/apache/drill/exec/udfs/UserAgentFunctions.java#L110])
> that has
> {code:java}
> @Param
> NullableVarCharHolder input;
> {code}
> and in the {code:java}eval(){code} function you do
> {code:java}String inputString =
> org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getStringFromVarCharHolder(input);{code}
> When this function is called with the input actually being null the 'input'
> parameter is an instance of NullableVarCharHolder where isSet is 0 and buffer
> is null.
> The buffer being null causes an NPE in the call to
> getStringFromVarCharHolder(NullableVarCharHolder)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DRILL-7677) NPE in getStringFromVarCharHolder(NullableVarCharHolder)
[
https://issues.apache.org/jira/browse/DRILL-7677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070953#comment-17070953
]
Niels Basjes commented on DRILL-7677:
-
This seems a sensible fix, yet I expect side effects and I'm currently no able
to verify the build locally.
{code:java}
diff --git
exec/java-exec/src/main/java/org/apache/drill/exec/expr/fn/impl/StringFunctionHelpers.java
exec/java-exec/src/main/java/org/apache/drill/exec/expr/fn/impl/StringFunctionHelpers.java
index 02b053f..8b26104 100644
---
exec/java-exec/src/main/java/org/apache/drill/exec/expr/fn/impl/StringFunctionHelpers.java
+++
exec/java-exec/src/main/java/org/apache/drill/exec/expr/fn/impl/StringFunctionHelpers.java
@@ -184,6 +184,9 @@ public class StringFunctionHelpers {
* Convert a NullableVarCharHolder to a String.
*/
public static String getStringFromVarCharHolder(NullableVarCharHolder
varCharHolder) {
+if (varCharHolder == null || varCharHolder.isSet == 0 ||
varCharHolder.buffer == null) {
+ return null;
+}
return toStringFromUTF8(varCharHolder.start, varCharHolder.end,
varCharHolder.buffer);
}
{code}
> NPE in getStringFromVarCharHolder(NullableVarCharHolder)
> -
>
> Key: DRILL-7677
> URL: https://issues.apache.org/jira/browse/DRILL-7677
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Niels Basjes
>Priority: Major
>
> Assume you have a function ([like this
> one|https://github.com/apache/drill/blob/master/contrib/udfs/src/main/java/org/apache/drill/exec/udfs/UserAgentFunctions.java#L110])
> that has
> {code:java}
> @Param
> NullableVarCharHolder input;
> {code}
> and in the {code:java}eval(){code} function you do
> {code:java}String inputString =
> org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getStringFromVarCharHolder(input);{code}
> When this function is called with the input actually being null the 'input'
> parameter is an instance of NullableVarCharHolder where isSet is 0 and buffer
> is null.
> The buffer being null causes an NPE in the call to
> getStringFromVarCharHolder(NullableVarCharHolder)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DRILL-7677) NPE in getStringFromVarCharHolder(NullableVarCharHolder)
[
https://issues.apache.org/jira/browse/DRILL-7677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070959#comment-17070959
]
Niels Basjes commented on DRILL-7677:
-
Yes, in this specific example it doesn't happen. I was trying some code of
myself and ran into this issue.
My point is that when a function has a parameter that is explicitly named
"Nullable" (which to me sounds very similar to the Java Optional ) and then if
it is actually the equivalent of "null" (i.e. content is not present, which is
an expected thing) it should not throw an exception. The pattern I would expect
in such a case is to get a null value or something similar.
So I was looking around in the code and a change like this would make sense to
me.
{code}
diff --git
exec/java-exec/src/main/java/org/apache/drill/exec/expr/fn/impl/StringFunctionHelpers.java
exec/java-exec/src/main/java/org/apache/drill/exec/expr/fn/impl/StringFunctionHelpers.java
index 02b053f..8b26104 100644
---
exec/java-exec/src/main/java/org/apache/drill/exec/expr/fn/impl/StringFunctionHelpers.java
+++
exec/java-exec/src/main/java/org/apache/drill/exec/expr/fn/impl/StringFunctionHelpers.java
@@ -184,6 +184,9 @@ public class StringFunctionHelpers {
* Convert a NullableVarCharHolder to a String.
*/
public static String getStringFromVarCharHolder(NullableVarCharHolder
varCharHolder) {
+ if (varCharHolder == null || varCharHolder.isSet == 0 || varCharHolder.buffer
== null) {
+ return null;
+ }
return toStringFromUTF8(varCharHolder.start, varCharHolder.end,
varCharHolder.buffer);
}
{code}
> NPE in getStringFromVarCharHolder(NullableVarCharHolder)
> -
>
> Key: DRILL-7677
> URL: https://issues.apache.org/jira/browse/DRILL-7677
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Niels Basjes
>Priority: Major
>
> Assume you have a function ([like this
> one|https://github.com/apache/drill/blob/master/contrib/udfs/src/main/java/org/apache/drill/exec/udfs/UserAgentFunctions.java#L110])
> that has
> {code:java}
> @Param
> NullableVarCharHolder input;
> {code}
> and in the {code:java}eval(){code} function you do
> {code:java}String inputString =
> org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getStringFromVarCharHolder(input);{code}
> When this function is called with the input actually being null the 'input'
> parameter is an instance of NullableVarCharHolder where isSet is 0 and buffer
> is null.
> The buffer being null causes an NPE in the call to
> getStringFromVarCharHolder(NullableVarCharHolder)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DRILL-7677) NPE in getStringFromVarCharHolder(NullableVarCharHolder)
[
https://issues.apache.org/jira/browse/DRILL-7677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070945#comment-17070945
]
Bohdan Kazydub commented on DRILL-7677:
---
In the example UDF you are referencing there is a [nullability
check|https://github.com/apache/drill/blob/master/contrib/udfs/src/main/java/org/apache/drill/exec/udfs/UserAgentFunctions.java#L104]
before calling the
{{org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getStringFromVarCharHolder(input)}}
to make sure this method is not invoked when {{input.isSet == 0}}. So no NPE
is thrown, is it?
Could you provide an example of the issue you're having, please?
> NPE in getStringFromVarCharHolder(NullableVarCharHolder)
> -
>
> Key: DRILL-7677
> URL: https://issues.apache.org/jira/browse/DRILL-7677
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Niels Basjes
>Priority: Major
>
> Assume you have a function ([like this
> one|https://github.com/apache/drill/blob/master/contrib/udfs/src/main/java/org/apache/drill/exec/udfs/UserAgentFunctions.java#L110])
> that has
> {code:java}
> @Param
> NullableVarCharHolder input;
> {code}
> and in the {code:java}eval(){code} function you do
> {code:java}String inputString =
> org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getStringFromVarCharHolder(input);{code}
> When this function is called with the input actually being null the 'input'
> parameter is an instance of NullableVarCharHolder where isSet is 0 and buffer
> is null.
> The buffer being null causes an NPE in the call to
> getStringFromVarCharHolder(NullableVarCharHolder)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (DRILL-7677) NPE in getStringFromVarCharHolder(NullableVarCharHolder)
[
https://issues.apache.org/jira/browse/DRILL-7677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niels Basjes updated DRILL-7677:
Comment: was deleted
(was: This seems a sensible fix, yet I expect side effects and I'm currently no
able to verify the build locally.
{code:java}
diff --git
exec/java-exec/src/main/java/org/apache/drill/exec/expr/fn/impl/StringFunctionHelpers.java
exec/java-exec/src/main/java/org/apache/drill/exec/expr/fn/impl/StringFunctionHelpers.java
index 02b053f..8b26104 100644
---
exec/java-exec/src/main/java/org/apache/drill/exec/expr/fn/impl/StringFunctionHelpers.java
+++
exec/java-exec/src/main/java/org/apache/drill/exec/expr/fn/impl/StringFunctionHelpers.java
@@ -184,6 +184,9 @@ public class StringFunctionHelpers {
* Convert a NullableVarCharHolder to a String.
*/
public static String getStringFromVarCharHolder(NullableVarCharHolder
varCharHolder) {
+if (varCharHolder == null || varCharHolder.isSet == 0 ||
varCharHolder.buffer == null) {
+ return null;
+}
return toStringFromUTF8(varCharHolder.start, varCharHolder.end,
varCharHolder.buffer);
}
{code})
> NPE in getStringFromVarCharHolder(NullableVarCharHolder)
> -
>
> Key: DRILL-7677
> URL: https://issues.apache.org/jira/browse/DRILL-7677
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Niels Basjes
>Priority: Major
>
> Assume you have a function ([like this
> one|https://github.com/apache/drill/blob/master/contrib/udfs/src/main/java/org/apache/drill/exec/udfs/UserAgentFunctions.java#L110])
> that has
> {code:java}
> @Param
> NullableVarCharHolder input;
> {code}
> and in the {code:java}eval(){code} function you do
> {code:java}String inputString =
> org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getStringFromVarCharHolder(input);{code}
> When this function is called with the input actually being null the 'input'
> parameter is an instance of NullableVarCharHolder where isSet is 0 and buffer
> is null.
> The buffer being null causes an NPE in the call to
> getStringFromVarCharHolder(NullableVarCharHolder)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DRILL-7677) NPE in getStringFromVarCharHolder(NullableVarCharHolder)
[
https://issues.apache.org/jira/browse/DRILL-7677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niels Basjes updated DRILL-7677:
Description:
Assume you have a function ([like this
one|https://github.com/apache/drill/blob/master/contrib/udfs/src/main/java/org/apache/drill/exec/udfs/UserAgentFunctions.java#L110])
that has
{code:java}
@Param
NullableVarCharHolder input;
{code}
and in the {code:java}eval(){code} function you do
{code:java}String inputString =
org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getStringFromVarCharHolder(input);{code}
When this function is called with the input actually being null the 'input'
parameter is an instance of NullableVarCharHolder where isSet is 0 and buffer
is null.
The buffer being null causes an NPE in the call to
getStringFromVarCharHolder(NullableVarCharHolder)
was:
Assume you have a function ([like this
one|https://github.com/apache/drill/blob/master/contrib/udfs/src/main/java/org/apache/drill/exec/udfs/UserAgentFunctions.java#L110])
that has
{code:java}
@Param
NullableVarCharHolder input;
{code}
and in the {code:java}eval(){code} function you do
{code:java}String inputString =
org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getStringFromVarCharHolder(input);code}
When this function is called with the input actually being null the 'input'
parameter is an instance of NullableVarCharHolder where isSet is 0 and buffer
is null.
The buffer being null causes an NPE in the call to
getStringFromVarCharHolder(NullableVarCharHolder)
> NPE in getStringFromVarCharHolder(NullableVarCharHolder)
> -
>
> Key: DRILL-7677
> URL: https://issues.apache.org/jira/browse/DRILL-7677
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Niels Basjes
>Priority: Major
>
> Assume you have a function ([like this
> one|https://github.com/apache/drill/blob/master/contrib/udfs/src/main/java/org/apache/drill/exec/udfs/UserAgentFunctions.java#L110])
> that has
> {code:java}
> @Param
> NullableVarCharHolder input;
> {code}
> and in the {code:java}eval(){code} function you do
> {code:java}String inputString =
> org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getStringFromVarCharHolder(input);{code}
> When this function is called with the input actually being null the 'input'
> parameter is an instance of NullableVarCharHolder where isSet is 0 and buffer
> is null.
> The buffer being null causes an NPE in the call to
> getStringFromVarCharHolder(NullableVarCharHolder)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (DRILL-7677) NPE in getStringFromVarCharHolder(NullableVarCharHolder)
Niels Basjes created DRILL-7677:
---
Summary: NPE in getStringFromVarCharHolder(NullableVarCharHolder)
Key: DRILL-7677
URL: https://issues.apache.org/jira/browse/DRILL-7677
Project: Apache Drill
Issue Type: Bug
Reporter: Niels Basjes
Assume you have a function ([like this
one|https://github.com/apache/drill/blob/master/contrib/udfs/src/main/java/org/apache/drill/exec/udfs/UserAgentFunctions.java#L110])
that has
{code:java}
@Param
NullableVarCharHolder input;
{code}
and in the {code:java}eval(){code} function you do
{code:java}String inputString =
org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getStringFromVarCharHolder(input);code}
When this function is called with the input actually being null the 'input'
parameter is an instance of NullableVarCharHolder where isSet is 0 and buffer
is null.
The buffer being null causes an NPE in the call to
getStringFromVarCharHolder(NullableVarCharHolder)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DRILL-7672) Make metadata type required when reading from / writing into Drill Metastore
[ https://issues.apache.org/jira/browse/DRILL-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070792#comment-17070792 ] ASF GitHub Bot commented on DRILL-7672: --- arina-ielchiieva commented on issue #2042: DRILL-7672: Make metadata type required when reading from / writing into Drill Metastore URL: https://github.com/apache/drill/pull/2042#issuecomment-605866287 @vvysotskyi thanks, @paul-rogers is the PR ok to go? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Make metadata type required when reading from / writing into Drill Metastore > > > Key: DRILL-7672 > URL: https://issues.apache.org/jira/browse/DRILL-7672 > Project: Apache Drill > Issue Type: Improvement >Affects Versions: 1.17.0 >Reporter: Arina Ielchiieva >Assignee: Arina Ielchiieva >Priority: Major > Labels: ready-to-commit > Fix For: 1.18.0 > > > Metastore consists of components: TABLES, VIEWS etc (so far only TABLES are > implemented). Each component metadata can have types. For examples, TABLES > metadata can be of the following types: TABLE, SEGMENT, FILE, ROW_GROUP, > PARTITION. > During initial Metastore implementation when reading from / writing into > Metastore, metadata type was indicated in filter expressions. > For Iceberg Metastore where all data is stored in files this was not this > critical, basically when information is retrieved about the table, table > folder is queried. > For other Metastore implementations knowing metadata type can be more > critical. For example, RDBMS Metastore would store TABLES metadata in > different tables thus knowing which table to query would improve performance > rather than trying to query all tables. > Of course, we could traverse query filter and look for the hints which > metadata type is needed but it is much better to know required metadata type > beforehand without any extra logic. > Taking into account that Metastore metadata is queried only in Drill code, > developer knows beforehand what he needs to get / update / delete. > This Jira aims to make metadata type required when reading from / writing > into Drill Metastore. This change does not have any affect on the users, just > internal code refactoring. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
