[jira] [Updated] (HIVE-22440) Beeline Stops Running Command At Comment
[
https://issues.apache.org/jira/browse/HIVE-22440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Weeks updated HIVE-22440:
---
Description:
This seems to be related to HIVE-13864 but I'm not sure that HIVE-16935 fixes
it as the example is different. Please flag as a dupe and close if that's the
case.
If you download the two attached files and run this command it's quits parsing
at the comment.
{{beeline -u jdbc:hive2://localhost:1 -f ./bug_run.sql}}
{{ Error: Error while compiling statement: FAILED: SemanticException [Error
10004]: Line 1:7 Invalid table alias or column reference 'c1': (possible column
names are: ) (state=42000,code=10004)}}
was:
This seems to be related to HIVE-13864 but I'm not sure that HIVE-16935 fixes
it as the example is different. Please flag as a dupe and close if that's the
case.
If you download the two attached files and run this command it's quits parsing
at the comment.
{{beeline -u jdbc:hive2://localhost:1 -f ./bug_run.sql}}
{{Connecting to jdbc:hive2://localhost:1/default
Connected to: Apache Hive (version 2.3.5-amzn-1)
Driver: Hive JDBC (version 2.3.5-amzn-1)
Transaction isolation: TRANSACTION_REPEATABLE_READ
0: jdbc:hive2://localhost:1/default> !run bug_example.sql
>>> create table if not exists bug_test (c1 string) stored as orc;
INFO : Compiling
command(queryId=hive_20191031141030_42617cb4-bff2-48a3-85f2-e4eb08997a71):
create table if not exists bug_test (c1 string) stored as orc
INFO : Semantic Analysis Completed
INFO : Returning Hive schema: Schema(fieldSchemas:null, properties:null)
INFO : Completed compiling
command(queryId=hive_20191031141030_42617cb4-bff2-48a3-85f2-e4eb08997a71); Time
taken: 0.005 seconds
INFO : Concurrency mode is disabled, not creating a lock manager
INFO : Executing
command(queryId=hive_20191031141030_42617cb4-bff2-48a3-85f2-e4eb08997a71):
create table if not exists bug_test (c1 string) stored as orc
INFO : Completed executing
command(queryId=hive_20191031141030_42617cb4-bff2-48a3-85f2-e4eb08997a71); Time
taken: 0.002 seconds
INFO : OK
No rows affected (0.048 seconds)
>>>
>>> select 'Hello World'
from bug_test;
INFO : Compiling
command(queryId=hive_20191031141030_b97f4ba2-7d18-49b8-a348-8316cc8ae144):
select 'Hello World'
from bug_test
INFO : Semantic Analysis Completed
INFO : Returning Hive schema: Schema(fieldSchemas:[FieldSchema(name:_c0,
type:string, comment:null)], properties:null)
INFO : Completed compiling
command(queryId=hive_20191031141030_b97f4ba2-7d18-49b8-a348-8316cc8ae144); Time
taken: 0.07 seconds
INFO : Concurrency mode is disabled, not creating a lock manager
INFO : Executing
command(queryId=hive_20191031141030_b97f4ba2-7d18-49b8-a348-8316cc8ae144):
select 'Hello World'
from bug_test
INFO : Completed executing
command(queryId=hive_20191031141030_b97f4ba2-7d18-49b8-a348-8316cc8ae144); Time
taken: 0.0 seconds
INFO : OK
+--+
| _c0 |
+--+
+--+
No rows selected (0.1 seconds)
>>>
>>> select c1 -- a comment
, c1 -- another comment
from bug_test;
. . . . . . . . . . . . . . . . . . . .>
. . . . . . . . . . . . . . . . . . . .> Error: Error while compiling
statement: FAILED: SemanticException [Error 10004]: Line 1:7 Invalid table
alias or column reference 'c1': (possible column names are: )
(state=42000,code=10004)
Aborting command set because "force" is false and command failed: "select c1 --
a comment
, c1 -- another comment
from bug_test;"
Closing: 0: jdbc:hive2://localhost:1/default}}
> Beeline Stops Running Command At Comment
>
>
> Key: HIVE-22440
> URL: https://issues.apache.org/jira/browse/HIVE-22440
> Project: Hive
> Issue Type: Bug
> Components: Beeline, CLI
>Reporter: Shawn Weeks
>Priority: Minor
> Attachments: bug_exec.sql, bug_run.sql
>
>
> This seems to be related to HIVE-13864 but I'm not sure that HIVE-16935 fixes
> it as the example is different. Please flag as a dupe and close if that's the
> case.
> If you download the two attached files and run this command it's quits
> parsing at the comment.
> {{beeline -u jdbc:hive2://localhost:1 -f ./bug_run.sql}}
> {{ Error: Error while compiling statement: FAILED: SemanticException [Error
> 10004]: Line 1:7 Invalid table alias or column reference 'c1': (possible
> column names are: ) (state=42000,code=10004)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HIVE-22390) Remove Dependency on JODA Time Library
[
https://issues.apache.org/jira/browse/HIVE-22390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16961450#comment-16961450
]
Shawn Weeks commented on HIVE-22390:
Moving to the next lts version of the jdk is completely reasonable though.
> Remove Dependency on JODA Time Library
> --
>
> Key: HIVE-22390
> URL: https://issues.apache.org/jira/browse/HIVE-22390
> Project: Hive
> Issue Type: Improvement
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
>
> Hive uses Joda time library.
> {quote}
> Joda-Time is the de facto standard date and time library for Java prior to
> Java SE 8. Users are now asked to migrate to java.time (JSR-310).
> https://www.joda.org/joda-time/
> {quote}
> Remove this dependency from classes, POM files, and licence files.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HIVE-22390) Remove Dependency on JODA Time Library
[
https://issues.apache.org/jira/browse/HIVE-22390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16961449#comment-16961449
]
Shawn Weeks commented on HIVE-22390:
This is the one I was thinking of.
https://bugs.openjdk.java.net/browse/JDK-8031085
> Remove Dependency on JODA Time Library
> --
>
> Key: HIVE-22390
> URL: https://issues.apache.org/jira/browse/HIVE-22390
> Project: Hive
> Issue Type: Improvement
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
>
> Hive uses Joda time library.
> {quote}
> Joda-Time is the de facto standard date and time library for Java prior to
> Java SE 8. Users are now asked to migrate to java.time (JSR-310).
> https://www.joda.org/joda-time/
> {quote}
> Remove this dependency from classes, POM files, and licence files.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HIVE-22390) Remove Dependency on JODA Time Library
[
https://issues.apache.org/jira/browse/HIVE-22390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16959701#comment-16959701
]
Shawn Weeks commented on HIVE-22390:
Of note. If your still on Java 8 their are unresolved bugs in java.time with
parsing fractional seconds. I don’t think it gets resolved until Java 9 or 11.
> Remove Dependency on JODA Time Library
> --
>
> Key: HIVE-22390
> URL: https://issues.apache.org/jira/browse/HIVE-22390
> Project: Hive
> Issue Type: Improvement
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
>
> Hive uses Joda time library.
> {quote}
> Joda-Time is the de facto standard date and time library for Java prior to
> Java SE 8. Users are now asked to migrate to java.time (JSR-310).
> https://www.joda.org/joda-time/
> {quote}
> Remove this dependency from classes, POM files, and licence files.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HIVE-21854) JDBC: Standalone Jar Breaks Spring Boot
[ https://issues.apache.org/jira/browse/HIVE-21854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918581#comment-16918581 ] Shawn Weeks commented on HIVE-21854: I’ll check this again as now there have been several dependencies removed from the jar. > JDBC: Standalone Jar Breaks Spring Boot > --- > > Key: HIVE-21854 > URL: https://issues.apache.org/jira/browse/HIVE-21854 > Project: Hive > Issue Type: Bug > Components: JDBC >Affects Versions: 3.0.0, 3.1.0, 3.1.1 >Reporter: Shawn Weeks >Priority: Major > Attachments: pom.xml > > > Much like HIVE-21417 since Hive 3.x the JDBC Standalone Jar includes > dependencies incompatible with the version of Tomcat included with Spring > Boot. Attached is an example Pom that shows the issue. Just place it in a > folder and run "mvn spring-boot:run" -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (HIVE-21885) Add pg-style dollar quoted string constant support
[
https://issues.apache.org/jira/browse/HIVE-21885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16865796#comment-16865796
]
Shawn Weeks commented on HIVE-21885:
Support for Oracle style quotes might also be useful here. For Oracle you
provide a q followed by a single quote and then delimiter you want to use. You
end the quote by using that delimter followed by another singel quote.
{code:sql}
begin
dbms_output.put_line(q'~'''Lots of Quotes'''~');
end;
/
{code}
> Add pg-style dollar quoted string constant support
> --
>
> Key: HIVE-21885
> URL: https://issues.apache.org/jira/browse/HIVE-21885
> Project: Hive
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Priority: Major
>
> I think it would be good to have a better option to supply constant string
> block for Hive
> Although I think the standard doesn't specify this - but I think the pg style
> "dollar-quote string constants" would be great.
> https://www.postgresql.org/docs/11/sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HIVE-21870) Toolkit CLI Kerberos Support
[ https://issues.apache.org/jira/browse/HIVE-21870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Weeks resolved HIVE-21870. Resolution: Abandoned Wrong project, gotta love Jira Autocomplete > Toolkit CLI Kerberos Support > > > Key: HIVE-21870 > URL: https://issues.apache.org/jira/browse/HIVE-21870 > Project: Hive > Issue Type: Improvement >Reporter: Shawn Weeks >Assignee: Shawn Weeks >Priority: Minor > > Add support for Kerberos Authentication in the NiFi Toolkit CLI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HIVE-21870) Toolkit CLI Kerberos Support
[ https://issues.apache.org/jira/browse/HIVE-21870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Weeks reassigned HIVE-21870: -- > Toolkit CLI Kerberos Support > > > Key: HIVE-21870 > URL: https://issues.apache.org/jira/browse/HIVE-21870 > Project: Hive > Issue Type: Improvement >Reporter: Shawn Weeks >Assignee: Shawn Weeks >Priority: Minor > > Add support for Kerberos Authentication in the NiFi Toolkit CLI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21854) JDBC: Standalone Jar Breaks Spring Boot
[ https://issues.apache.org/jira/browse/HIVE-21854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860967#comment-16860967 ] Shawn Weeks commented on HIVE-21854: The Pom just demonstrates the issue. Sorry for being unclear. > JDBC: Standalone Jar Breaks Spring Boot > --- > > Key: HIVE-21854 > URL: https://issues.apache.org/jira/browse/HIVE-21854 > Project: Hive > Issue Type: Bug > Components: JDBC >Affects Versions: 3.0.0, 3.1.0, 3.1.1 >Reporter: Shawn Weeks >Priority: Major > Attachments: pom.xml > > > Much like HIVE-21417 since Hive 3.x the JDBC Standalone Jar includes > dependencies incompatible with the version of Tomcat included with Spring > Boot. Attached is an example Pom that shows the issue. Just place it in a > folder and run "mvn spring-boot:run" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21854) JDBC: Standalone Jar Breaks Spring Boot
[ https://issues.apache.org/jira/browse/HIVE-21854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860323#comment-16860323 ] Shawn Weeks commented on HIVE-21854: I don't currently have a patch for this, just ran into this weekend. If I get a chance I'll try just adding Jetty to the exclusions for the JDBC Driver and see what it breaks. > JDBC: Standalone Jar Breaks Spring Boot > --- > > Key: HIVE-21854 > URL: https://issues.apache.org/jira/browse/HIVE-21854 > Project: Hive > Issue Type: Bug > Components: JDBC >Affects Versions: 3.0.0, 3.1.0, 3.1.1 >Reporter: Shawn Weeks >Priority: Major > Attachments: pom.xml > > > Much like HIVE-21417 since Hive 3.x the JDBC Standalone Jar includes > dependencies incompatible with the version of Tomcat included with Spring > Boot. Attached is an example Pom that shows the issue. Just place it in a > folder and run "mvn spring-boot:run" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21854) JDBC: Standalone Jar Breaks Spring Boot
[ https://issues.apache.org/jira/browse/HIVE-21854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860274#comment-16860274 ] Shawn Weeks commented on HIVE-21854: The issue appears to be coming from the Jetty Dependency and a mismatch of org.apache.tomcat.util.scan.StandardJarScanner. I thought shading was supposed to prevent this kind of issue? > JDBC: Standalone Jar Breaks Spring Boot > --- > > Key: HIVE-21854 > URL: https://issues.apache.org/jira/browse/HIVE-21854 > Project: Hive > Issue Type: Bug > Components: JDBC >Affects Versions: 3.0.0, 3.1.0, 3.1.1 >Reporter: Shawn Weeks >Priority: Major > Attachments: pom.xml > > > Much like HIVE-21417 since Hive 3.x the JDBC Standalone Jar includes > dependencies incompatible with the version of Tomcat included with Spring > Boot. Attached is an example Pom that shows the issue. Just place it in a > folder and run "mvn spring-boot:run" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21820) drop database command flushing other data outside db folder
[ https://issues.apache.org/jira/browse/HIVE-21820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853983#comment-16853983 ] Shawn Weeks commented on HIVE-21820: I think this expected behavior. You have to include the abc.db folder in the location if you wanted it created there. The location parameter is the entire path for the database not the starting path. > drop database command flushing other data outside db folder > --- > > Key: HIVE-21820 > URL: https://issues.apache.org/jira/browse/HIVE-21820 > Project: Hive > Issue Type: Bug >Reporter: Neeraj Maheshwari >Priority: Blocker > > On running the below command to create new database: > *create database abc location /users/hive/warehouse/project_name/;* > here expected is, this command should create a new db folder named abc.db > under project_name directory, but with hive version 1.2.1000.2.6.3.0-235 its > not creating abc.db folder. > > And on running command *drop database abc;* the entire project_name directory > got deleted from HDFS. So here drop command rather than dropping just one db > it deleted whole directory and just retained meta informations in hive > metastore for other dbs present in project_name directory. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21576) Introduce CAST...FORMAT and limited list of SQL:2016 datetime formats
[ https://issues.apache.org/jira/browse/HIVE-21576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16833785#comment-16833785 ] Shawn Weeks commented on HIVE-21576: Is there any plan to include fractional seconds. That seems to be consistently missing across all the time stamp functions. > Introduce CAST...FORMAT and limited list of SQL:2016 datetime formats > - > > Key: HIVE-21576 > URL: https://issues.apache.org/jira/browse/HIVE-21576 > Project: Hive > Issue Type: Improvement >Reporter: Karen Coppage >Assignee: Karen Coppage >Priority: Major > Attachments: HIVE-21576.01.patch > > > Introduce FORMAT clause to CAST statements as well as the below limited list > of SQL:2016 datetime formats to Hive in general. These can be used if a > session-level feature flag is turned on. > * > * MM > * DD > * HH > * MI > * SS > Definitions of these formats here: > [https://docs.google.com/document/d/1V7k6-lrPGW7_uhqM-FhKl3QsxwCRy69v2KIxPsGjc1k/|https://docs.google.com/document/d/1V7k6-lrPGW7_uhqM-FhKl3QsxwCRy69v2KIxPsGjc1k/edit] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21560) Update Derby DDL to use CLOB instead of LONG VARCHAR
[ https://issues.apache.org/jira/browse/HIVE-21560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16807046#comment-16807046 ] Shawn Weeks commented on HIVE-21560: I tested this and changing the two columns to clob didn’t seem to break anything. I was able to create views more 32kb and queries against them didn’t fail. > Update Derby DDL to use CLOB instead of LONG VARCHAR > > > Key: HIVE-21560 > URL: https://issues.apache.org/jira/browse/HIVE-21560 > Project: Hive > Issue Type: Bug >Reporter: Shawn Weeks >Assignee: Rajkumar Singh >Priority: Minor > > in the Hive 1.x and 2.x metastore version for Derby there are two column in > "TBLS" that are set to LONG VARCHAR. This causes larger create view > statements to fail when using embedded metastore for testing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21409) Initial SessionState ClassLoader Reused For Subsequent Sessions
[ https://issues.apache.org/jira/browse/HIVE-21409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16796834#comment-16796834 ] Shawn Weeks commented on HIVE-21409: So far I've identified that the Apache Atlas Hook and the RangerHiveAuthorizer are both modify the current threads classloader without consideration for the current threads existing classloader. It probably wouldn't be an issue if they were just adding to the classloader but it looks like they're completely replacing it with one from another session. > Initial SessionState ClassLoader Reused For Subsequent Sessions > --- > > Key: HIVE-21409 > URL: https://issues.apache.org/jira/browse/HIVE-21409 > Project: Hive > Issue Type: Bug >Affects Versions: 1.2.1 >Reporter: Shawn Weeks >Priority: Minor > Attachments: create_class.sql, run.sql, setup.sql > > > It appears that the first ClassLoader attached to a SessionState Static > Instance is being reused as the parent for all future sessions. This causes > any libraries added to the class path on the initial session to be added to > future sessions. It also appears that further sessions may be adding jars to > this initial ClassLoader as well leading to the class path getting more and > more polluted. This occurring on a build including HIVE-11878. I've included > some examples that greatly exaggerate the problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HIVE-21409) Initial SessionState ClassLoader Reused For Subsequent Sessions
[ https://issues.apache.org/jira/browse/HIVE-21409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16796834#comment-16796834 ] Shawn Weeks edited comment on HIVE-21409 at 3/20/19 6:14 AM: - So far I've identified that the Apache Atlas Hook and the RangerHiveAuthorizer are both modifying the current threads classloader without consideration for the current threads existing classloader. It probably wouldn't be an issue if they were just adding to the classloader but it looks like they're completely replacing it with one from another session. was (Author: absolutesantaja): So far I've identified that the Apache Atlas Hook and the RangerHiveAuthorizer are both modify the current threads classloader without consideration for the current threads existing classloader. It probably wouldn't be an issue if they were just adding to the classloader but it looks like they're completely replacing it with one from another session. > Initial SessionState ClassLoader Reused For Subsequent Sessions > --- > > Key: HIVE-21409 > URL: https://issues.apache.org/jira/browse/HIVE-21409 > Project: Hive > Issue Type: Bug >Affects Versions: 1.2.1 >Reporter: Shawn Weeks >Priority: Minor > Attachments: create_class.sql, run.sql, setup.sql > > > It appears that the first ClassLoader attached to a SessionState Static > Instance is being reused as the parent for all future sessions. This causes > any libraries added to the class path on the initial session to be added to > future sessions. It also appears that further sessions may be adding jars to > this initial ClassLoader as well leading to the class path getting more and > more polluted. This occurring on a build including HIVE-11878. I've included > some examples that greatly exaggerate the problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21409) Initial SessionState ClassLoader Reused For Subsequent Sessions
[ https://issues.apache.org/jira/browse/HIVE-21409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16796783#comment-16796783 ] Shawn Weeks commented on HIVE-21409: I've spent a lot of time tracking this down and I've run into a dead end with a call to ReflectionUtils in HiveUtils. getAuthorizerFactory. For some reason this call is changing the class loader for the current thread. > Initial SessionState ClassLoader Reused For Subsequent Sessions > --- > > Key: HIVE-21409 > URL: https://issues.apache.org/jira/browse/HIVE-21409 > Project: Hive > Issue Type: Bug >Affects Versions: 1.2.1 >Reporter: Shawn Weeks >Priority: Minor > Attachments: create_class.sql, run.sql, setup.sql > > > It appears that the first ClassLoader attached to a SessionState Static > Instance is being reused as the parent for all future sessions. This causes > any libraries added to the class path on the initial session to be added to > future sessions. It also appears that further sessions may be adding jars to > this initial ClassLoader as well leading to the class path getting more and > more polluted. This occurring on a build including HIVE-11878. I've included > some examples that greatly exaggerate the problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21409) Initial SessionState ClassLoader Reused For Subsequent Sessions
[ https://issues.apache.org/jira/browse/HIVE-21409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16795587#comment-16795587 ] Shawn Weeks commented on HIVE-21409: I've verified this bug in Hive 3.1 as well. A combination of Add Jar and implicitly added UDF Jars pollute the session classloader. > Initial SessionState ClassLoader Reused For Subsequent Sessions > --- > > Key: HIVE-21409 > URL: https://issues.apache.org/jira/browse/HIVE-21409 > Project: Hive > Issue Type: Bug >Affects Versions: 1.2.1 >Reporter: Shawn Weeks >Priority: Minor > Attachments: create_class.sql, run.sql, setup.sql > > > It appears that the first ClassLoader attached to a SessionState Static > Instance is being reused as the parent for all future sessions. This causes > any libraries added to the class path on the initial session to be added to > future sessions. It also appears that further sessions may be adding jars to > this initial ClassLoader as well leading to the class path getting more and > more polluted. This occurring on a build including HIVE-11878. I've included > some examples that greatly exaggerate the problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-2816) Extend IMPORT/EXPORT with metadata only option
[ https://issues.apache.org/jira/browse/HIVE-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16794557#comment-16794557 ] Shawn Weeks commented on HIVE-2816: --- I think it would be useful. I’ve had to build some tools to do this for testing deployments. It would be great if you could dump the metadata to a common format and import on another system. > Extend IMPORT/EXPORT with metadata only option > -- > > Key: HIVE-2816 > URL: https://issues.apache.org/jira/browse/HIVE-2816 > Project: Hive > Issue Type: New Feature > Components: Import/Export >Reporter: Carl Steinbach >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-17061) Add Support for Column List in Insert Clause
[
https://issues.apache.org/jira/browse/HIVE-17061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790519#comment-16790519
]
Shawn Weeks commented on HIVE-17061:
Looks like HIVE-20590 may have been a duplicate of this.
> Add Support for Column List in Insert Clause
>
>
> Key: HIVE-17061
> URL: https://issues.apache.org/jira/browse/HIVE-17061
> Project: Hive
> Issue Type: Improvement
> Components: Transactions
>Reporter: Shawn Weeks
>Priority: Minor
>
> Include support for a list of columns in the insert clause of the merge
> statement. This helps when you may not know or care about the order of
> columns in the target table or if you don't want to have to insert values
> into all of the columns.
> {code}
> MERGE INTO target
> USING source ON b = y
> WHEN MATCHED AND c + 1 + z > 0
> THEN UPDATE SET a = 1, c = z
> WHEN NOT MATCHED AND z IS NULL
> THEN INSERT(a,b) VALUES(z, 7)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HIVE-20590) Allow merge statement to have column schema
[ https://issues.apache.org/jira/browse/HIVE-20590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790517#comment-16790517 ] Shawn Weeks commented on HIVE-20590: Isn't this a duplicate of HIVE-17061? > Allow merge statement to have column schema > --- > > Key: HIVE-20590 > URL: https://issues.apache.org/jira/browse/HIVE-20590 > Project: Hive > Issue Type: Improvement > Components: Transactions >Reporter: Vineet Garg >Assignee: Miklos Gergely >Priority: Major > Fix For: 4.0.0 > > Attachments: HIVE-20590.01.patch, HIVE-20590.03.patch, > HIVE-20590.04.patch, HIVE-20590.05.patch, HIVE-20590.06.patch > > > Currently MERGE statement doesn't let user specify column schema with INSERT > statements, therefore DEFAULT constraint are not applicable with it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21409) Initial SessionState ClassLoader Reused For Subsequent Sessions
[ https://issues.apache.org/jira/browse/HIVE-21409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16788350#comment-16788350 ] Shawn Weeks commented on HIVE-21409: I've changed registerJars in SessionState to get the classLoader from SessionState.getConf().getClassLoader() instead of the thread context and it seems to have cleared up the class loader pollution. Not 100% sure what it's doing or why the thread context at that point doesn't already have the session state's class loader. > Initial SessionState ClassLoader Reused For Subsequent Sessions > --- > > Key: HIVE-21409 > URL: https://issues.apache.org/jira/browse/HIVE-21409 > Project: Hive > Issue Type: Bug >Affects Versions: 1.2.1 >Reporter: Shawn Weeks >Priority: Minor > Attachments: create_class.sql, run.sql, setup.sql > > > It appears that the first ClassLoader attached to a SessionState Static > Instance is being reused as the parent for all future sessions. This causes > any libraries added to the class path on the initial session to be added to > future sessions. It also appears that further sessions may be adding jars to > this initial ClassLoader as well leading to the class path getting more and > more polluted. This occurring on a build including HIVE-11878. I've included > some examples that greatly exaggerate the problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-21409) Initial SessionState ClassLoader Reused For Subsequent Sessions
[ https://issues.apache.org/jira/browse/HIVE-21409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Weeks updated HIVE-21409: --- Description: It appears that the first ClassLoader attached to a SessionState Static Instance is being reused as the parent for all future sessions. This causes any libraries added to the class path on the initial session to be added to future sessions. It also appears that further sessions may be adding jars to this initial ClassLoader as well leading to the class path getting more and more polluted. This occurring on a build including HIVE-11878. I've included some examples that greatly exaggerate the problem. (was: While trying to reproduce another bug I've ran across something interesting. It appears that the first session to a hiveserver2 instance after startup is able to contaminate the class path for subsequent sessions. I've written a small groovy udf to dump the current session class path as well as it's parents and in the attached example any jar added to class path in the initial session is present in future sessions. I've tried adding other jars as well and the behavior is there for all of them. To demonstrate run setup.sql then restart the hiveserver2 instance. Then run run.sql and notice the last query after reconnect. I've only tested this so far on the HDP 2.6.5 release of Hive but it may be present on other versions.) Summary: Initial SessionState ClassLoader Reused For Subsequent Sessions (was: First Hive Session Class Path Additions Added to All Sessions) > Initial SessionState ClassLoader Reused For Subsequent Sessions > --- > > Key: HIVE-21409 > URL: https://issues.apache.org/jira/browse/HIVE-21409 > Project: Hive > Issue Type: Bug >Affects Versions: 1.2.1 >Reporter: Shawn Weeks >Priority: Minor > Attachments: create_class.sql, run.sql, setup.sql > > > It appears that the first ClassLoader attached to a SessionState Static > Instance is being reused as the parent for all future sessions. This causes > any libraries added to the class path on the initial session to be added to > future sessions. It also appears that further sessions may be adding jars to > this initial ClassLoader as well leading to the class path getting more and > more polluted. This occurring on a build including HIVE-11878. I've included > some examples that greatly exaggerate the problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21375) Closing TransactionBatch closes FileSystem for other batches
[ https://issues.apache.org/jira/browse/HIVE-21375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16786164#comment-16786164 ] Shawn Weeks commented on HIVE-21375: HIVE-19772 doesn't appear to modify the V1 Streaming API. I may be reading the patch completely wrong though. > Closing TransactionBatch closes FileSystem for other batches > > > Key: HIVE-21375 > URL: https://issues.apache.org/jira/browse/HIVE-21375 > Project: Hive > Issue Type: Bug > Components: HCatalog, Streaming >Reporter: Shawn Weeks >Priority: Minor > > The patch in HIVE-13151 added FileSystem.closeAllForUGI(ugi); to the close > method of HiveEndPoint for the legacy Streaming API. This seems to have a > side effect of closing the FileSystem for all open TransactionBatches as used > by NiFi and Storm when writing to multiple partitions. Setting > fs.hdfs.impl.disable.cache=true negates the issue but at a performance cost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21375) Closing TransactionBatch closes FileSystem for other batches
[ https://issues.apache.org/jira/browse/HIVE-21375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16784893#comment-16784893 ] Shawn Weeks commented on HIVE-21375: Same issue for ConnectionImpl as well. Closing the file system here will cause a problem if you have multiple connections or transaction batches open. This type of cleanup should probably be handled by the caller. > Closing TransactionBatch closes FileSystem for other batches > > > Key: HIVE-21375 > URL: https://issues.apache.org/jira/browse/HIVE-21375 > Project: Hive > Issue Type: Bug > Components: HCatalog, Streaming >Reporter: Shawn Weeks >Priority: Minor > > The patch in HIVE-13151 added FileSystem.closeAllForUGI(ugi); to the close > method of HiveEndPoint for the legacy Streaming API. This seems to have a > side effect of closing the FileSystem for all open TransactionBatches as used > by NiFi and Storm when writing to multiple partitions. Setting > fs.hdfs.impl.disable.cache=true negates the issue but at a performance cost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-9004) Reset doesn't work for the default empty value entry
[ https://issues.apache.org/jira/browse/HIVE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16773084#comment-16773084 ] Shawn Weeks commented on HIVE-9004: --- Any reason why this never got done. Currently working an issue where the reset command doesn't reset tez defaults like tez.runtime.io.sort.mb if you change them at the session level. > Reset doesn't work for the default empty value entry > > > Key: HIVE-9004 > URL: https://issues.apache.org/jira/browse/HIVE-9004 > Project: Hive > Issue Type: Bug > Components: Configuration >Reporter: Cheng Hao >Assignee: Cheng Hao >Priority: Major > Attachments: HIVE-9004.patch > > > To illustrate that: > In hive cli: > hive> set hive.table.parameters.default; > hive.table.parameters.default is undefined > hive> set hive.table.parameters.default=key1=value1; > hive> reset; > hive> set hive.table.parameters.default; > hive.table.parameters.default=key1=value1 > I think we expect the last output as "hive.table.parameters.default is > undefined" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21144) ODBC with prepared statement fail inside a CTE
[
https://issues.apache.org/jira/browse/HIVE-21144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754288#comment-16754288
]
Shawn Weeks commented on HIVE-21144:
I suspect it's going to be an issue with the Hortonworks ODBC Driver which is
licensed from Simba. I don't believe Hive itself actually supports binding
parameters so everything is being handled by the driver. I know on the JDBC
side even when you use parameters the stringified version is what Hive sees
with the parameters expanded.
> ODBC with prepared statement fail inside a CTE
> --
>
> Key: HIVE-21144
> URL: https://issues.apache.org/jira/browse/HIVE-21144
> Project: Hive
> Issue Type: Bug
> Components: ODBC
>Affects Versions: 3.1.0
>Reporter: Guillaume
>Priority: Major
>
> I am trying to execute a very simple query, using python/pyodbc on Windows
> (with a working system-wide odbc DSN: HiveProd):
> {code:java}
> import pyodbc cnxn = pyodbc.connect('DSN=HiveProd', autocommit=True)
> cursor = cnxn.cursor()
> # works
> q="select ? as lic, ? as cpg"
> # fails
> q="with init as (select ? as lic, ? as cpg) select * from init"
> cursor.execute(q, '1', 'some string')
> for row in cursor:
> print(row.lic, row.cpg)
> {code}
> Basically, create an odbc connection, run a query with a prepared statement
> and print the result.
> A basic query works fine. If I put this query inside a CTE, I get:
> {{ cursor.execute("with init as (select ? as lic, ? as cpg) select * from
> init", '1', 'some string') pyodbc.ProgrammingError: ('42000', "[42000]
> [Hortonworks][Hardy] (80) Syntax or semantic analysis error thrown in server
> while executing query. Error message from server: Error while compiling
> statement: FAILED: ParseException line 1:21 can not recognize input near '?'
> 'as' 'lic' in select clause (80) (SQLPrepare)")}}
> This is not specific to python as I get the same issue with .Net.
> Trying the same with JDBC works fine.
> Testing on Hive 3.1.0 from Hdp 3.1.0
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HIVE-21144) ODBC with prepared statement fail inside a CTE
[
https://issues.apache.org/jira/browse/HIVE-21144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754256#comment-16754256
]
Shawn Weeks commented on HIVE-21144:
Check and make sure that the ODBC Driver your using is using "Native Queries".
Several of the Hive ODBC Drivers try and rewrite your queries and may be
messing with the CTE. Also if possible check the hiverserver2 logs and see if
you can figure out exactly what query Hive received.
> ODBC with prepared statement fail inside a CTE
> --
>
> Key: HIVE-21144
> URL: https://issues.apache.org/jira/browse/HIVE-21144
> Project: Hive
> Issue Type: Bug
> Components: ODBC
>Affects Versions: 3.1.0
>Reporter: Guillaume
>Priority: Major
>
> I am trying to execute a very simple query, using python/pyodbc on Windows
> (with a working system-wide odbc DSN: HiveProd):
> {code:java}
> import pyodbc cnxn = pyodbc.connect('DSN=HiveProd', autocommit=True)
> cursor = cnxn.cursor()
> # works
> q="select ? as lic, ? as cpg"
> # fails
> q="with init as (select ? as lic, ? as cpg) select * from init"
> cursor.execute(q, '1', 'some string')
> for row in cursor:
> print(row.lic, row.cpg)
> {code}
> Basically, create an odbc connection, run a query with a prepared statement
> and print the result.
> A basic query works fine. If I put this query inside a CTE, I get:
> {{ cursor.execute("with init as (select ? as lic, ? as cpg) select * from
> init", '1', 'some string') pyodbc.ProgrammingError: ('42000', "[42000]
> [Hortonworks][Hardy] (80) Syntax or semantic analysis error thrown in server
> while executing query. Error message from server: Error while compiling
> statement: FAILED: ParseException line 1:21 can not recognize input near '?'
> 'as' 'lic' in select clause (80) (SQLPrepare)")}}
> This is not specific to python as I get the same issue with .Net.
> Trying the same with JDBC works fine.
> Testing on Hive 3.1.0 from Hdp 3.1.0
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HIVE-20012) Implement SQL Standard Date and Timestamp Functions
[
https://issues.apache.org/jira/browse/HIVE-20012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16658087#comment-16658087
]
Shawn Weeks commented on HIVE-20012:
I've created an initial version of the to_timestamp UDF. Currently the project
I'm working on is still using Hive 1.2.1 so I've had to stick to older versions
of some classes. If someone as interested and has suggestions you can take a
look at https://github.com/shawnweeks/hive-udf.
> Implement SQL Standard Date and Timestamp Functions
> ---
>
> Key: HIVE-20012
> URL: https://issues.apache.org/jira/browse/HIVE-20012
> Project: Hive
> Issue Type: New Feature
>Reporter: Shawn Weeks
>Priority: Minor
>
> I've looked around and haven't seen an existing ticket on this. Many times
> you need to convert from arbitrary string formats to a date or a timestamp.
> The current method using the unix_timestamp function doesn't support
> milliseconds and is a bit clunky. I propose we implement a to_date and
> to_timestamp function that behave like the following. It may also be useful
> for the to_timestamp function to behave like the existing to_date function
> and convert Hive's default timestamp string into an actual timestamp.
> {code:java}
> select to_date('01-01-2000','dd-MM-');
> 2000-01-01
> select to_timestamp('01-01-2000 13:00:00.000','dd-MM- HH:mm:ss.SSS')
> 2000-01-01 13:00:00.000{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HIVE-17713) disallow adding/modifying columns in metastore for Avro/CSV/etc. SerDes
[ https://issues.apache.org/jira/browse/HIVE-17713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644206#comment-16644206 ] Shawn Weeks commented on HIVE-17713: While I understand why you wouldn't want this for files that embed or reference an external schema, whats the reason for file formats backed by things like the OpenCSVSerde, MultiDelimiterSerde and RegexSerde. Their schema isn't being derived external and they're generally just specialized replacements for the default LazySimpleSerde. > disallow adding/modifying columns in metastore for Avro/CSV/etc. SerDes > --- > > Key: HIVE-17713 > URL: https://issues.apache.org/jira/browse/HIVE-17713 > Project: Hive > Issue Type: Bug >Reporter: Sergey Shelukhin >Priority: Major > > This is kind of a followup from HIVE-11985 > When a SerDe uses an external schema (either embedded, or via a file link), > it's not using the information stored in metastore for the columns. So, if > the users modify table schema via add column and other such commands it won't > have effect on the serde, since it's using the external schema to figure out > what the columns are; leading to confusion and bugs. We should not allow such > a modification for SerDes not in hive.serdes.using.metastore.for.schema -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-16116) Beeline throws NPE when beeline.hiveconfvariables={} in beeline.properties
[
https://issues.apache.org/jira/browse/HIVE-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16578878#comment-16578878
]
Shawn Weeks commented on HIVE-16116:
In case anyone else runs across this. This error will also occur if this line
is set in beeline.properties "beeline.hiveconfvariables=" it doesn't have to
have the brackets and it might NPE on line 679. I've been dealing with an issue
in Oozie due to this for a week.
> Beeline throws NPE when beeline.hiveconfvariables={} in beeline.properties
> --
>
> Key: HIVE-16116
> URL: https://issues.apache.org/jira/browse/HIVE-16116
> Project: Hive
> Issue Type: Bug
> Components: Beeline
>Reporter: Rajesh Balamohan
>Assignee: Rajesh Balamohan
>Priority: Minor
> Attachments: HIVE-16116.1.patch, HIVE-16116.2.patch
>
>
> Env: hive master
> Steps to reproduce:
> 1. clear previous beeline.properties (rm -rf ~/.beeline/beeline.properties)
> 2. Launch beeline, "!save" and exit. This would create new
> "~/.beeline/beeline.properties", which would have
> "beeline.hiveconfvariables={}"
> 3. Launch "beeline --hiveconf hive.tmp.dir=/tmp". This would throw NPE
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at org.apache.hive.beeline.BeeLine.setHiveConfVar(BeeLine.java:885)
> at org.apache.hive.beeline.BeeLine.connectUsingArgs(BeeLine.java:832)
> at org.apache.hive.beeline.BeeLine.initArgs(BeeLine.java:775)
> at org.apache.hive.beeline.BeeLine.begin(BeeLine.java:1009)
> at
> org.apache.hive.beeline.BeeLine.mainWithInputRedirection(BeeLine.java:519)
> at org.apache.hive.beeline.BeeLine.main(BeeLine.java:501)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.hadoop.util.RunJar.run(RunJar.java:233)
> at org.apache.hadoop.util.RunJar.main(RunJar.java:148)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HIVE-9252) Linking custom SerDe jar to table definition.
[
https://issues.apache.org/jira/browse/HIVE-9252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16562272#comment-16562272
]
Shawn Weeks commented on HIVE-9252:
---
Can we make this also support loading the InputFormat and RecordReader this
way? Many times with more unusual formats you'll need more than just a Serde to
read it.
> Linking custom SerDe jar to table definition.
> -
>
> Key: HIVE-9252
> URL: https://issues.apache.org/jira/browse/HIVE-9252
> Project: Hive
> Issue Type: New Feature
> Components: Serializers/Deserializers
>Reporter: Niels Basjes
>Assignee: Ferdinand Xu
>Priority: Major
> Attachments: HIVE-9252.1.patch
>
>
> In HIVE-6047 the option was created that a jar file can be hooked to the
> definition of a function. (See: [Language Manual DDL: Permanent
> Functions|https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-PermanentFunctions]
> )
> I propose to add something similar that can be used when defining an external
> table that relies on a custom Serde (I expect to usually only have the
> Deserializer).
> Something like this:
> {code}
> CREATE [TEMPORARY] [EXTERNAL] TABLE [IF NOT EXISTS] [db_name.]table_name
> ...
> STORED BY 'storage.handler.class.name' [WITH SERDEPROPERTIES (...)]
> [USING JAR|FILE|ARCHIVE 'file_uri' [, JAR|FILE|ARCHIVE 'file_uri'] ];
> {code}
> Using this you can define (and share !!!) a Hive table on top of a custom
> fileformat without the need to let the IT operations people deploy a custom
> SerDe jar file on all nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HIVE-20012) Implement SQL Standard Date and Timestamp Functions
[
https://issues.apache.org/jira/browse/HIVE-20012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16553158#comment-16553158
]
Shawn Weeks commented on HIVE-20012:
[~bharos92] Sorry for the delay. If we make it behave like Oracle than it will
either accept two strings, or some type that is cast-able to a timestamp or
date. For example in Oracle to_timestamp will accept a date as a single
parameter and cast it to a timestamp. All of my use cases though are for
explicit converting a string to timestamp or date.
> Implement SQL Standard Date and Timestamp Functions
> ---
>
> Key: HIVE-20012
> URL: https://issues.apache.org/jira/browse/HIVE-20012
> Project: Hive
> Issue Type: New Feature
>Reporter: Shawn Weeks
>Priority: Minor
>
> I've looked around and haven't seen an existing ticket on this. Many times
> you need to convert from arbitrary string formats to a date or a timestamp.
> The current method using the unix_timestamp function doesn't support
> milliseconds and is a bit clunky. I propose we implement a to_date and
> to_timestamp function that behave like the following. It may also be useful
> for the to_timestamp function to behave like the existing to_date function
> and convert Hive's default timestamp string into an actual timestamp.
> {code:java}
> select to_date('01-01-2000','dd-MM-');
> 2000-01-01
> select to_timestamp('01-01-2000 13:00:00.000','dd-MM- HH:mm:ss.SSS')
> 2000-01-01 13:00:00.000{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HIVE-20012) Implement SQL Standard Date and Timestamp Functions
[
https://issues.apache.org/jira/browse/HIVE-20012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537282#comment-16537282
]
Shawn Weeks commented on HIVE-20012:
Go for it if you can, I was going to look at it over the break but didn't get a
chance. For timestamps there is already a string parser implemented in the
TimestampParser class so it would be mostly just a case of instantianting it
with the user input value.
> Implement SQL Standard Date and Timestamp Functions
> ---
>
> Key: HIVE-20012
> URL: https://issues.apache.org/jira/browse/HIVE-20012
> Project: Hive
> Issue Type: New Feature
>Reporter: Shawn Weeks
>Priority: Minor
>
> I've looked around and haven't seen an existing ticket on this. Many times
> you need to convert from arbitrary string formats to a date or a timestamp.
> The current method using the unix_timestamp function doesn't support
> milliseconds and is a bit clunky. I propose we implement a to_date and
> to_timestamp function that behave like the following. It may also be useful
> for the to_timestamp function to behave like the existing to_date function
> and convert Hive's default timestamp string into an actual timestamp.
> {code:java}
> select to_date('01-01-2000','dd-MM-');
> 2000-01-01
> select to_timestamp('01-01-2000 13:00:00.000','dd-MM- HH:mm:ss.SSS')
> 2000-01-01 13:00:00.000{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HIVE-20020) Hive contrib jar should not be in lib
[ https://issues.apache.org/jira/browse/HIVE-20020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16529277#comment-16529277 ] Shawn Weeks commented on HIVE-20020: Yeah, and really what I was trying to say is that aside from the MultiDelimiterSerde, just about everything else in there is just examples. If we could get out of there what's actually being used we could quit include hive-contrib altogether. I don't really see how compiled copies of the examples actually belongs in the standard installation. > Hive contrib jar should not be in lib > - > > Key: HIVE-20020 > URL: https://issues.apache.org/jira/browse/HIVE-20020 > Project: Hive > Issue Type: Improvement > Components: Contrib >Reporter: Johndee Burks >Priority: Trivial > > Currently the way hive is packaged it includes hive-contrib-.jar in > lib, we should not include it here because it is picked up by services like > HS2. This creates a situation in which experimental features such as the > [MultiDelimitSerDe|https://github.com/apache/hive/blob/master/contrib/src/java/org/apache/hadoop/hive/contrib/serde2/MultiDelimitSerDe.java] > are accessible without understanding how to really install and use it. For > example you can create a table using HS2 via beeline with the aforementioned > SerDe and it will work as long you do not do M/R jobs. The M/R jobs do not > work because the SerDe is not in aux to get shipped into distcache. I propose > we do not package it this way and if someone would like to leverage an > experimental feature they can add it manually to their environment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-20020) Hive contrib jar should not be in lib
[ https://issues.apache.org/jira/browse/HIVE-20020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16529203#comment-16529203 ] Shawn Weeks commented on HIVE-20020: MultiDelimitSerDe has been in contrib for several years now, what is needed to actually make it a proper SerDe so we can just eliminate the issue altogether? I know it still has a rather nasty bug in it and I've gone to using the Hive split() function instead but I don't think it's that much work to fix that. > Hive contrib jar should not be in lib > - > > Key: HIVE-20020 > URL: https://issues.apache.org/jira/browse/HIVE-20020 > Project: Hive > Issue Type: Improvement > Components: Contrib >Reporter: Johndee Burks >Priority: Trivial > > Currently the way hive is packaged it includes hive-contrib-.jar in > lib, we should not include it here because it is picked up by services like > HS2. This creates a situation in which experimental features such as the > [MultiDelimitSerDe|https://github.com/apache/hive/blob/master/contrib/src/java/org/apache/hadoop/hive/contrib/serde2/MultiDelimitSerDe.java] > are accessible without understanding how to really install and use it. For > example you can create a table using HS2 via beeline with the aforementioned > SerDe and it will work as long you do not do M/R jobs. The M/R jobs do not > work because the SerDe is not in aux to get shipped into distcache. I propose > we do not package it this way and if someone would like to leverage an > experimental feature they can add it manually to their environment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-5737) Provide StructObjectInspector for UDTFs rather than ObjectInspect[]
[
https://issues.apache.org/jira/browse/HIVE-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345348#comment-16345348
]
Shawn Weeks commented on HIVE-5737:
---
Was this ever fully implemented? I can't find any examples of anyone using this
and Hive gives me a semantic error when I try to include column names in a call
to a custom udtf that I'm writing. I've verified that this patch is included in
the release I'm working with.
select xml_explode('','blah' as col1,'blah' as col2)
SQL Error [4] [42000]: Error while compiling statement: FAILED:
ParseException line 1:40 missing ) at 'as' near ''
line 1:62 extraneous input ')' expecting EOF near ''
Error while compiling statement: FAILED: ParseException line 1:40 missing )
at 'as' near ''
line 1:62 extraneous input ')' expecting EOF near ''
Error while compiling statement: FAILED: ParseException line 1:40 missing )
at 'as' near ''
line 1:62 extraneous input ')' expecting EOF near ''
org.apache.hadoop.hive.ql.parse.ParseException:line 1:40 missing ) at
'as' near ''
line 1:62 extraneous input ')' expecting EOF near ''
org.apache.hadoop.hive.ql.parse.ParseException:line 1:40 missing ) at
'as' near ''
line 1:62 extraneous input ')' expecting EOF near ''
> Provide StructObjectInspector for UDTFs rather than ObjectInspect[]
> ---
>
> Key: HIVE-5737
> URL: https://issues.apache.org/jira/browse/HIVE-5737
> Project: Hive
> Issue Type: Improvement
> Components: UDF
>Reporter: Navis
>Assignee: Navis
>Priority: Trivial
> Fix For: 0.13.0
>
> Attachments: HIVE-5737.1.patch.txt
>
>
> In UDTF, column names can be useful sometimes. For example, complex function
> with many optional parameters something like,
> xml_explode('\t' as field, '\n' as line, '=' as mapkey, ':' as items, input)
> Without column name, it's not easy to discern each parameter is for what.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (HIVE-14867) "serialization.last.column.takes.rest" does not work for MultiDelimitSerDe
[
https://issues.apache.org/jira/browse/HIVE-14867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Weeks updated HIVE-14867:
---
Comment: was deleted
(was: Ran across this issue troubleshooting for a customer. This essentially
makes this serde useless as it's always going to throw garbage in the last
column. Is there a reason we can't just add multi character field delimiters to
other text serde and deprecate this one as it doesn't appear to be getting
maintained.)
> "serialization.last.column.takes.rest" does not work for MultiDelimitSerDe
> --
>
> Key: HIVE-14867
> URL: https://issues.apache.org/jira/browse/HIVE-14867
> Project: Hive
> Issue Type: Bug
> Components: Serializers/Deserializers
>Affects Versions: 1.3.0
>Reporter: Niklaus Xiao
>Assignee: Niklaus Xiao
>
> Create table with MultiDelimitSerde:
> {code}
> CREATE TABLE foo (a string, b string) ROW FORMAT SERDE
> 'org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe' WITH
> SERDEPROPERTIES
> ("field.delim"="|@|","collection.delim"=":","mapkey.delim"="@") stored as
> textfile;
> {code}
> load data into table:
> {code}
> 1|@|Lily|@|HW|@|abc
> 2|@|Lucy|@|LX|@|123
> 3|@|Lilei|@|XX|@|3434
> {code}
> select data from this table:
> {code}
> select * from foo;
> +-++--+
> | foo.a | foo.b |
> +-++--+
> | 1 | Lily^AHW^Aabc|
> | 2 | Lucy^ALX^A123|
> | 3 | Lilei^AXX^A3434 |
> +-++--+
> 3 rows selected (0.905 seconds)
> {code}
> You can see the last column takes all the data, and replace the delimiter to
> default ^A.
> lastColumnTakesRestString should be false by default:
> {code}
> String lastColumnTakesRestString = tbl
> .getProperty(serdeConstants.SERIALIZATION_LAST_COLUMN_TAKES_REST);
> lastColumnTakesRest = (lastColumnTakesRestString != null &&
> lastColumnTakesRestString
> .equalsIgnoreCase("true"));
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HIVE-14867) "serialization.last.column.takes.rest" does not work for MultiDelimitSerDe
[
https://issues.apache.org/jira/browse/HIVE-14867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16207575#comment-16207575
]
Shawn Weeks commented on HIVE-14867:
Ran across this issue troubleshooting for a customer. This essentially makes
this serde useless as it's always going to throw garbage in the last column. Is
there a reason we can't just add multi character field delimiters to other text
serde and deprecate this one as it doesn't appear to be getting maintained.
> "serialization.last.column.takes.rest" does not work for MultiDelimitSerDe
> --
>
> Key: HIVE-14867
> URL: https://issues.apache.org/jira/browse/HIVE-14867
> Project: Hive
> Issue Type: Bug
> Components: Serializers/Deserializers
>Affects Versions: 1.3.0
>Reporter: Niklaus Xiao
>Assignee: Niklaus Xiao
>
> Create table with MultiDelimitSerde:
> {code}
> CREATE TABLE foo (a string, b string) ROW FORMAT SERDE
> 'org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe' WITH
> SERDEPROPERTIES
> ("field.delim"="|@|","collection.delim"=":","mapkey.delim"="@") stored as
> textfile;
> {code}
> load data into table:
> {code}
> 1|@|Lily|@|HW|@|abc
> 2|@|Lucy|@|LX|@|123
> 3|@|Lilei|@|XX|@|3434
> {code}
> select data from this table:
> {code}
> select * from foo;
> +-++--+
> | foo.a | foo.b |
> +-++--+
> | 1 | Lily^AHW^Aabc|
> | 2 | Lucy^ALX^A123|
> | 3 | Lilei^AXX^A3434 |
> +-++--+
> 3 rows selected (0.905 seconds)
> {code}
> You can see the last column takes all the data, and replace the delimiter to
> default ^A.
> lastColumnTakesRestString should be false by default:
> {code}
> String lastColumnTakesRestString = tbl
> .getProperty(serdeConstants.SERIALIZATION_LAST_COLUMN_TAKES_REST);
> lastColumnTakesRest = (lastColumnTakesRestString != null &&
> lastColumnTakesRestString
> .equalsIgnoreCase("true"));
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HIVE-17027) HPL/SQL requires single quotes for string literals, resulting in surprising behavior
[
https://issues.apache.org/jira/browse/HIVE-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16117115#comment-16117115
]
Shawn Weeks commented on HIVE-17027:
>From an Oracle perspective double and single quotes mean very different things
>and treating them the same would lead to unpredictable behavior. Not sure how
>MySQL and Postgres handle this but in Oracle double quotes are used to quote
>object names with special characters while Hive uses backticks to do the same
>thing.
> HPL/SQL requires single quotes for string literals, resulting in surprising
> behavior
>
>
> Key: HIVE-17027
> URL: https://issues.apache.org/jira/browse/HIVE-17027
> Project: Hive
> Issue Type: Bug
> Components: hpl/sql
>Reporter: Carter Shanklin
>Priority: Critical
>
> This bug is part of a series of issues and surprising behavior I encountered
> writing a reporting script that would aggregate values and give rows
> different classifications based on an the aggregate. Addressing some or all
> of these issues would make HPL/SQL more accessible to newcomers.
> Consider this script:
> {code}
> CREATE FUNCTION test1()
> RETURNS STRING
> DECLARE
> VAR ret string;
> BEGIN
> ret := 'VALUE IS SET';
> print(ret);
> END;
> CREATE FUNCTION test2()
> RETURNS STRING
> DECLARE
> VAR ret string;
> BEGIN
> ret := "VALUE IS SET";
> print(ret);
> END;
> test1();
> test2();
> {code}
> The output of this script is:
> VALUE IS SET
> ret
> Hive accepts both quoting styles. It would be better if HPL/SQL did as well,
> or threw an error for th
> e unsupported style.
> Version = 3.0.0-SNAPSHOT r71f52d8ad512904b3f2c4f04fe39a33f2834f1f2
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HIVE-10924) add support for MERGE statement
[ https://issues.apache.org/jira/browse/HIVE-10924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078728#comment-16078728 ] Shawn Weeks commented on HIVE-10924: I added HIVE-17061 for this. > add support for MERGE statement > --- > > Key: HIVE-10924 > URL: https://issues.apache.org/jira/browse/HIVE-10924 > Project: Hive > Issue Type: New Feature > Components: Query Planning, Query Processor, Transactions >Affects Versions: 1.2.0 >Reporter: Eugene Koifman >Assignee: Eugene Koifman > > add support for > MERGE INTO tbl USING src ON … WHEN MATCHED THEN ... WHEN NOT MATCHED THEN ... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HIVE-17061) Add Support for Column List in Insert Clause
[
https://issues.apache.org/jira/browse/HIVE-17061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Weeks updated HIVE-17061:
---
Description:
Include support for a list of columns in the insert clause of the merge
statement. This helps when you may not know or care about the order of columns
in the target table or if you don't want to have to insert values into all of
the columns.
{code}
MERGE INTO target
USING source ON b = y
WHEN MATCHED AND c + 1 + z > 0
THEN UPDATE SET a = 1, c = z
WHEN NOT MATCHED AND z IS NULL
THEN INSERT(a,b) VALUES(z, 7)
{code}
was:
Include support for a list of columns in the insert clause of the merge
statement.
{code}
MERGE INTO target
USING source ON b = y
WHEN MATCHED AND c + 1 + z > 0
THEN UPDATE SET a = 1, c = z
WHEN NOT MATCHED AND z IS NULL
THEN INSERT(a,b) VALUES(z, 7)
{code}
> Add Support for Column List in Insert Clause
>
>
> Key: HIVE-17061
> URL: https://issues.apache.org/jira/browse/HIVE-17061
> Project: Hive
> Issue Type: Sub-task
> Components: Hive
>Reporter: Shawn Weeks
>Priority: Minor
>
> Include support for a list of columns in the insert clause of the merge
> statement. This helps when you may not know or care about the order of
> columns in the target table or if you don't want to have to insert values
> into all of the columns.
> {code}
> MERGE INTO target
> USING source ON b = y
> WHEN MATCHED AND c + 1 + z > 0
> THEN UPDATE SET a = 1, c = z
> WHEN NOT MATCHED AND z IS NULL
> THEN INSERT(a,b) VALUES(z, 7)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HIVE-17061) Add Support for Column List in Insert Clause
[
https://issues.apache.org/jira/browse/HIVE-17061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Weeks updated HIVE-17061:
---
Description:
Include support for a list of columns in the insert clause of the merge
statement.
{code}
MERGE INTO target
USING source ON b = y
WHEN MATCHED AND c + 1 + z > 0
THEN UPDATE SET a = 1, c = z
WHEN NOT MATCHED AND z IS NULL
THEN INSERT(a,b) VALUES(z, 7)
{code}
was:
Include support for a list of columns in the insert clause of the merge
statement.
MERGE INTO target
USING source ON b = y
WHEN MATCHED AND c + 1 + z > 0
THEN UPDATE SET a = 1, c = z
WHEN NOT MATCHED AND z IS NULL
THEN INSERT(a,b) VALUES(z, 7)
> Add Support for Column List in Insert Clause
>
>
> Key: HIVE-17061
> URL: https://issues.apache.org/jira/browse/HIVE-17061
> Project: Hive
> Issue Type: Sub-task
> Components: Hive
>Reporter: Shawn Weeks
>Priority: Minor
>
> Include support for a list of columns in the insert clause of the merge
> statement.
> {code}
> MERGE INTO target
> USING source ON b = y
> WHEN MATCHED AND c + 1 + z > 0
> THEN UPDATE SET a = 1, c = z
> WHEN NOT MATCHED AND z IS NULL
> THEN INSERT(a,b) VALUES(z, 7)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HIVE-10924) add support for MERGE statement
[ https://issues.apache.org/jira/browse/HIVE-10924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078693#comment-16078693 ] Shawn Weeks commented on HIVE-10924: I noticed the existing implementation doesn't support listing the target table columns for insert as seen in the example "THEN INSERT(a,b) VALUES(z, 7)". This is important if you only want to insert certain columns or may not know the order of the columns ahead of time. Is there an intent to support this part of the syntax? > add support for MERGE statement > --- > > Key: HIVE-10924 > URL: https://issues.apache.org/jira/browse/HIVE-10924 > Project: Hive > Issue Type: New Feature > Components: Query Planning, Query Processor, Transactions >Affects Versions: 1.2.0 >Reporter: Eugene Koifman >Assignee: Eugene Koifman > > add support for > MERGE INTO tbl USING src ON … WHEN MATCHED THEN ... WHEN NOT MATCHED THEN ... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HIVE-16883) HBaseStorageHandler Ignores Case for HBase Table Name
[
https://issues.apache.org/jira/browse/HIVE-16883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Weeks updated HIVE-16883:
---
Description:
Currently the HBaseStorageHandler is lower casing the HBase Table name. This
prevent use of the storage handler with existing HBase tables that are not all
lower case. Looking at the source this was done intentionally but I haven't
found any documentation about why on the wiki. To prevent a change in the
default behavior I'd suggest adding an additional property to the serde.
{code}
create 'TestTable', 'd'
create external table `TestTable` (
id bigint,
hash String,
location String,
name String
)
stored by "org.apache.hadoop.hive.hbase.HBaseStorageHandler"
with serdeproperties (
"hbase.columns.mapping" = ":key,d:hash,d:location,d:name",
"hbase.table.name" = "TestTable"
);
{code}
was:
Currently the HBaseStorageHandler is lower casing the HBase Table name. This
prevent use of the storage handler with existing HBase tables that are not all
lower case.
{code}
create 'TestTable', 'd'
create external table `TestTable` (
id bigint,
hash String,
location String,
name String
)
stored by "org.apache.hadoop.hive.hbase.HBaseStorageHandler"
with serdeproperties (
"hbase.columns.mapping" = ":key,d:hash,d:location,d:name",
"hbase.table.name" = "TestTable"
);
{code}
> HBaseStorageHandler Ignores Case for HBase Table Name
> -
>
> Key: HIVE-16883
> URL: https://issues.apache.org/jira/browse/HIVE-16883
> Project: Hive
> Issue Type: Bug
> Components: HBase Handler
>Affects Versions: 1.2.1
> Environment: Hortonworks HDP 2.6.0.3, CentOS 7.0, VMWare ESXI
>Reporter: Shawn Weeks
>Priority: Minor
>
> Currently the HBaseStorageHandler is lower casing the HBase Table name. This
> prevent use of the storage handler with existing HBase tables that are not
> all lower case. Looking at the source this was done intentionally but I
> haven't found any documentation about why on the wiki. To prevent a change in
> the default behavior I'd suggest adding an additional property to the serde.
> {code}
> create 'TestTable', 'd'
> create external table `TestTable` (
> id bigint,
> hash String,
> location String,
> name String
> )
> stored by "org.apache.hadoop.hive.hbase.HBaseStorageHandler"
> with serdeproperties (
> "hbase.columns.mapping" = ":key,d:hash,d:location,d:name",
> "hbase.table.name" = "TestTable"
> );
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HIVE-16883) HBaseStorageHandler Ignores Case for HBase Table Name
[
https://issues.apache.org/jira/browse/HIVE-16883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16046428#comment-16046428
]
Shawn Weeks edited comment on HIVE-16883 at 6/12/17 10:41 AM:
--
{code}
FAILED: Execution Error, return code 1 from
org.apache.hadoop.hive.ql.exec.DDLTask.
MetaException(message:MetaException(message:HBase table testtable doesn't exist
while the table is declared as an external table.)
at
org.apache.hadoop.hive.hbase.HBaseStorageHandler.preCreateTable(HBaseStorageHandler.java:234)
at
org.apache.hadoop.hive.metastore.HiveMetaStoreClient.createTable(HiveMetaStoreClient.java:730)
at
org.apache.hadoop.hive.metastore.HiveMetaStoreClient.createTable(HiveMetaStoreClient.java:723)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.hadoop.hive.metastore.RetryingMetaStoreClient.invoke(RetryingMetaStoreClient.java:178)
at com.sun.proxy.$Proxy5.createTable(Unknown Source)
at org.apache.hadoop.hive.ql.metadata.Hive.createTable(Hive.java:762)
at org.apache.hadoop.hive.ql.exec.DDLTask.createTable(DDLTask.java:4409)
at org.apache.hadoop.hive.ql.exec.DDLTask.execute(DDLTask.java:316)
at org.apache.hadoop.hive.ql.exec.Task.executeTask(Task.java:160)
at
org.apache.hadoop.hive.ql.exec.TaskRunner.runSequential(TaskRunner.java:89)
at org.apache.hadoop.hive.ql.Driver.launchTask(Driver.java:1748)
at org.apache.hadoop.hive.ql.Driver.execute(Driver.java:1494)
at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:1291)
at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1158)
at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1148)
at
org.apache.hadoop.hive.cli.CliDriver.processLocalCmd(CliDriver.java:217)
at org.apache.hadoop.hive.cli.CliDriver.processCmd(CliDriver.java:169)
at org.apache.hadoop.hive.cli.CliDriver.processLine(CliDriver.java:380)
at
org.apache.hadoop.hive.cli.CliDriver.executeDriver(CliDriver.java:740)
at org.apache.hadoop.hive.cli.CliDriver.run(CliDriver.java:685)
at org.apache.hadoop.hive.cli.CliDriver.main(CliDriver.java:625)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.hadoop.util.RunJar.run(RunJar.java:233)
at org.apache.hadoop.util.RunJar.main(RunJar.java:148)
)
{code}
was (Author: absolutesantaja):
{code}
create 'TestTable', 'd'
create external table `TestTable` (
id bigint,
hash String,
location String,
name String
)
stored by "org.apache.hadoop.hive.hbase.HBaseStorageHandler"
with serdeproperties (
"hbase.columns.mapping" = ":key,d:hash,d:location,d:name",
"hbase.table.name" = "TestTable"
);
{code}
> HBaseStorageHandler Ignores Case for HBase Table Name
> -
>
> Key: HIVE-16883
> URL: https://issues.apache.org/jira/browse/HIVE-16883
> Project: Hive
> Issue Type: Bug
> Components: HBase Handler
>Affects Versions: 1.2.1
> Environment: Hortonworks HDP 2.6.0.3, CentOS 7.0, VMWare ESXI
>Reporter: Shawn Weeks
>Priority: Minor
>
> Currently the HBaseStorageHandler is lower casing the HBase Table name. This
> prevent use of the storage handler with existing HBase tables that are not
> all lower case.
> {code}
> create 'TestTable', 'd'
> create external table `TestTable` (
> id bigint,
> hash String,
> location String,
> name String
> )
> stored by "org.apache.hadoop.hive.hbase.HBaseStorageHandler"
> with serdeproperties (
> "hbase.columns.mapping" = ":key,d:hash,d:location,d:name",
> "hbase.table.name" = "TestTable"
> );
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HIVE-16883) HBaseStorageHandler Ignores Case for HBase Table Name
[
https://issues.apache.org/jira/browse/HIVE-16883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16046428#comment-16046428
]
Shawn Weeks commented on HIVE-16883:
{code}
create 'TestTable', 'd'
create external table `TestTable` (
id bigint,
hash String,
location String,
name String
)
stored by "org.apache.hadoop.hive.hbase.HBaseStorageHandler"
with serdeproperties (
"hbase.columns.mapping" = ":key,d:hash,d:location,d:name",
"hbase.table.name" = "TestTable"
);
{code}
> HBaseStorageHandler Ignores Case for HBase Table Name
> -
>
> Key: HIVE-16883
> URL: https://issues.apache.org/jira/browse/HIVE-16883
> Project: Hive
> Issue Type: Bug
> Components: HBase Handler
>Affects Versions: 1.2.1
> Environment: Hortonworks HDP 2.6.0.3, CentOS 7.0, VMWare ESXI
>Reporter: Shawn Weeks
>Priority: Minor
>
> Currently the HBaseStorageHandler is lower casing the HBase Table name. This
> prevent use of the storage handler with existing HBase tables that are not
> all lower case.
> {code}
> create 'TestTable', 'd'
> create external table `TestTable` (
> id bigint,
> hash String,
> location String,
> name String
> )
> stored by "org.apache.hadoop.hive.hbase.HBaseStorageHandler"
> with serdeproperties (
> "hbase.columns.mapping" = ":key,d:hash,d:location,d:name",
> "hbase.table.name" = "TestTable"
> );
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HIVE-15692) Can't Create Table with Interval Column Type
[
https://issues.apache.org/jira/browse/HIVE-15692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Weeks updated HIVE-15692:
---
Description:
You can create a table with an interval type via create table as select but not
directly with create table.
This works
{code}
create table test_interval
as
select interval '1' day as day_interval,
interval '1' month as month_interval;
{code}
{code}
describe test_interval;
+-+--+--+--+
|col_name | data_type | comment |
+-+--+--+--+
| day_interval| interval_day_time| |
| month_interval | interval_year_month | |
+-+--+--+--+
{code}
This raises an error.
{code}
create table test_interval(
day_interval interval_day_time,
month_interval interval_year_month
);
{code}
was:
You can create a table with an interval type via create table as select but not
directly with create table.
This works
create table test_interval
as
select interval '1' day as day_interval,
interval '1' month as month_interval;
This raises an error.
create table test_interval(
day_interval interval_day_time,
month_interval interval_year_month
);
> Can't Create Table with Interval Column Type
>
>
> Key: HIVE-15692
> URL: https://issues.apache.org/jira/browse/HIVE-15692
> Project: Hive
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.2.1
> Environment: CentOS 6.8 Hortonworks HDP 2.5 Apache Hive (version
> 1.2.1000.2.5.3.0-37)
>Reporter: Shawn Weeks
>Priority: Minor
>
> You can create a table with an interval type via create table as select but
> not directly with create table.
> This works
> {code}
> create table test_interval
> as
> select interval '1' day as day_interval,
> interval '1' month as month_interval;
> {code}
> {code}
> describe test_interval;
> +-+--+--+--+
> |col_name | data_type | comment |
> +-+--+--+--+
> | day_interval| interval_day_time| |
> | month_interval | interval_year_month | |
> +-+--+--+--+
> {code}
> This raises an error.
> {code}
> create table test_interval(
>
>day_interval interval_day_time,
>
>month_interval interval_year_month
>);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HIVE-15692) Can't Create Table with Interval Column Type
[
https://issues.apache.org/jira/browse/HIVE-15692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Weeks updated HIVE-15692:
---
Description:
You can create a table with an interval type via create table as select but not
directly with create table.
This works
create table test_interval
as
select interval '1' day as day_interval,
interval '1' month as month_interval;
This raises an error.
create table test_interval(
day_interval interval_day_time,
month_interval interval_year_month
);
was:
You can create a table with an interval type via create table as select but not
directly with create table.
This Works
{{create table test_interval}}
{{as}}
{{selectinterval '1' day as day_interval,}}
{{ interval '1' month as month_interval;}}
This raises an error.
{{create table test_interval(
day_interval interval_day_time,
month_interval interval_year_month
);}}
> Can't Create Table with Interval Column Type
>
>
> Key: HIVE-15692
> URL: https://issues.apache.org/jira/browse/HIVE-15692
> Project: Hive
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.2.1
> Environment: CentOS 6.8 Hortonworks HDP 2.5 Apache Hive (version
> 1.2.1000.2.5.3.0-37)
>Reporter: Shawn Weeks
>Priority: Minor
>
> You can create a table with an interval type via create table as select but
> not directly with create table.
> This works
> create table test_interval
> as
> selectinterval '1' day as day_interval,
> interval '1' month as month_interval;
> This raises an error.
> create table test_interval(
>
>day_interval interval_day_time,
>
>month_interval interval_year_month
>);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HIVE-15692) Can't Create Table with Interval Column Type
[
https://issues.apache.org/jira/browse/HIVE-15692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Weeks updated HIVE-15692:
---
Description:
You can create a table with an interval type via create table as select but not
directly with create table.
This Works
{{create table test_interval}}
{{as}}
{{selectinterval '1' day as day_interval,}}
{{ interval '1' month as month_interval;}}
This raises an error.
{{create table test_interval(
day_interval interval_day_time,
month_interval interval_year_month
);}}
was:
You can create a table with an interval type via create table as select but not
directly with create table.
This Works
bq.
create table test_interval
as
select interval '1' day as day_interval,
interval '1' month as month_interval;
This raises an error.
{{create table test_interval(
day_interval interval_day_time,
month_interval interval_year_month
);}}
> Can't Create Table with Interval Column Type
>
>
> Key: HIVE-15692
> URL: https://issues.apache.org/jira/browse/HIVE-15692
> Project: Hive
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.2.1
> Environment: CentOS 6.8 Hortonworks HDP 2.5 Apache Hive (version
> 1.2.1000.2.5.3.0-37)
>Reporter: Shawn Weeks
>Priority: Minor
>
> You can create a table with an interval type via create table as select but
> not directly with create table.
> This Works
> {{create table test_interval}}
> {{as}}
> {{select interval '1' day as day_interval,}}
> {{interval '1' month as month_interval;}}
> This raises an error.
> {{create table test_interval(
>
>day_interval interval_day_time,
>
>month_interval interval_year_month
>);}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HIVE-15692) Can't Create Table with Interval Column Type
[
https://issues.apache.org/jira/browse/HIVE-15692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Weeks updated HIVE-15692:
---
Description:
You can create a table with an interval type via create table as select but not
directly with create table.
This Works
{{
create table test_interval
as
select interval '1' day as day_interval,
interval '1' month as month_interval;
}}
This raises an error.
{{create table test_interval(
day_interval interval_day_time,
month_interval interval_year_month
);}}
was:
You can create a table with an interval type via create table as select but not
directly with create table.
This Works
{{monospaced}}
create table test_interval
as
select interval '1' day as day_interval,
interval '1' month as month_interval;
This raises an error.
{{create table test_interval(
day_interval interval_day_time,
month_interval interval_year_month
);}}
> Can't Create Table with Interval Column Type
>
>
> Key: HIVE-15692
> URL: https://issues.apache.org/jira/browse/HIVE-15692
> Project: Hive
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.2.1
> Environment: CentOS 6.8 Hortonworks HDP 2.5 Apache Hive (version
> 1.2.1000.2.5.3.0-37)
>Reporter: Shawn Weeks
>Priority: Minor
>
> You can create a table with an interval type via create table as select but
> not directly with create table.
> This Works
> {{
> create table test_interval
> as
> selectinterval '1' day as day_interval,
> interval '1' month as month_interval;
> }}
> This raises an error.
> {{create table test_interval(
>
>day_interval interval_day_time,
>
>month_interval interval_year_month
>);}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HIVE-15692) Can't Create Table with Interval Column Type
[
https://issues.apache.org/jira/browse/HIVE-15692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Weeks updated HIVE-15692:
---
Description:
You can create a table with an interval type via create table as select but not
directly with create table.
This Works
bq.
create table test_interval
as
select interval '1' day as day_interval,
interval '1' month as month_interval;
This raises an error.
{{create table test_interval(
day_interval interval_day_time,
month_interval interval_year_month
);}}
was:
You can create a table with an interval type via create table as select but not
directly with create table.
This Works
{{
create table test_interval
as
select interval '1' day as day_interval,
interval '1' month as month_interval;
}}
This raises an error.
{{create table test_interval(
day_interval interval_day_time,
month_interval interval_year_month
);}}
> Can't Create Table with Interval Column Type
>
>
> Key: HIVE-15692
> URL: https://issues.apache.org/jira/browse/HIVE-15692
> Project: Hive
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.2.1
> Environment: CentOS 6.8 Hortonworks HDP 2.5 Apache Hive (version
> 1.2.1000.2.5.3.0-37)
>Reporter: Shawn Weeks
>Priority: Minor
>
> You can create a table with an interval type via create table as select but
> not directly with create table.
> This Works
> bq.
> create table test_interval
> as
> selectinterval '1' day as day_interval,
> interval '1' month as month_interval;
> This raises an error.
> {{create table test_interval(
>
>day_interval interval_day_time,
>
>month_interval interval_year_month
>);}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HIVE-15692) Can't Create Table with Interval Column Type
[
https://issues.apache.org/jira/browse/HIVE-15692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Weeks updated HIVE-15692:
---
Description:
You can create a table with an interval type via create table as select but not
directly with create table.
This Works
{{monospaced}}
create table test_interval
as
select interval '1' day as day_interval,
interval '1' month as month_interval;
This raises an error.
{{create table test_interval(
day_interval interval_day_time,
month_interval interval_year_month
);}}
was:
You can create a table with an interval type via create table as select but not
directly with create table.
This Works
{{create table test_interval
as
select interval '1' day as day_interval,
interval '1' month as month_interval;}}
This raises an error.
{{create table test_interval(
day_interval interval_day_time,
month_interval interval_year_month
);}}
> Can't Create Table with Interval Column Type
>
>
> Key: HIVE-15692
> URL: https://issues.apache.org/jira/browse/HIVE-15692
> Project: Hive
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.2.1
> Environment: CentOS 6.8 Hortonworks HDP 2.5 Apache Hive (version
> 1.2.1000.2.5.3.0-37)
>Reporter: Shawn Weeks
>Priority: Minor
>
> You can create a table with an interval type via create table as select but
> not directly with create table.
> This Works
> {{monospaced}}
> create table test_interval
> as
> selectinterval '1' day as day_interval,
> interval '1' month as month_interval;
> This raises an error.
> {{create table test_interval(
>
>day_interval interval_day_time,
>
>month_interval interval_year_month
>);}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HIVE-6720) Implement getURL()
[ https://issues.apache.org/jira/browse/HIVE-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15444569#comment-15444569 ] Shawn Weeks commented on HIVE-6720: --- Just found this issue while troubleshooting Netbeans support for the Hive2 JDBC. Raising his an exception instead of returning null breaks Netbeans so that you can't even run simple select statements. > Implement getURL() > --- > > Key: HIVE-6720 > URL: https://issues.apache.org/jira/browse/HIVE-6720 > Project: Hive > Issue Type: Bug > Components: JDBC >Affects Versions: 0.12.0 >Reporter: Jonathan Seidman >Priority: Minor > > DatabaseMetaData.getURL() throws an unsupported exception. This should be > modified to return a valid value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
