[jira] [Created] (HIVE-24789) Unable to verify hive-1.2.2 integrity
Sebastian created HIVE-24789: Summary: Unable to verify hive-1.2.2 integrity Key: HIVE-24789 URL: https://issues.apache.org/jira/browse/HIVE-24789 Project: Hive Issue Type: Bug Components: Hive Affects Versions: 1.2.2 Reporter: Sebastian h3. *Steps to reproduce* Run the following commands - {noformat} curl -fSL -o KEYS https://archive.apache.org/dist/hive/KEYS export HIVE_VERSION=1.2.2 curl -fSL -o hive.tar.gz https://archive.apache.org/dist/hadoop/common/hadoop-${HADOOP_VERSION}/hadoop-${HADOOP_VERSION}.tar.gz curl -fSL -o hive.tar.gz.asc https://archive.apache.org/dist/hadoop/common/hadoop-${HADOOP_VERSION}/hadoop-${HADOOP_VERSION}.tar.gz.asc export GNUPGHOME="$(mktemp -d)" gpg --import KEYS gpg --verify hive.tar.gz.asc hive.tar.gz {noformat} h3. *Expected Result* {noformat} gpg: Signature made Sun Apr 2 20:16:19 2017 UTC gpg:using RSA key F2384CC9084FCC30 gpg: Good signature from "Vaibhav Gumashta (CODE SIGNING KEY) " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 2FF7 1C57 D64C 9AB4 F21A 68D7 F238 4CC9 084F CC30 {noformat} h3. *Actual Result* It seems that the file [KEYS|https://archive.apache.org/dist/hive/KEYS] file is missing the key *F2384CC9084FCC30* {noformat} $ gpg --verify hive.tar.gz.asc hive.tar.gz gpg: Signature made Sun Apr 2 20:16:19 2017 UTC gpg:using RSA key F2384CC9084FCC30 gpg: Can't check signature: No public key# {noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HIVE-19952) Error
Sebastian created HIVE-19952: Summary: Error Key: HIVE-19952 URL: https://issues.apache.org/jira/browse/HIVE-19952 Project: Hive Issue Type: Bug Reporter: Sebastian I am joining 2 tables (hive tables in radoop rapidminer) and I am getting this error, someone knows why? * Message: HiveQL error. Message: org.apache.hive.service.cli.HiveSQLException: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. java.lang.IllegalArgumentException: Can not create a Path from an ... Thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HIVE-16089) "trustStorePassword" is logged as part of jdbc connection url
Sebastian created HIVE-16089: Summary: "trustStorePassword" is logged as part of jdbc connection url Key: HIVE-16089 URL: https://issues.apache.org/jira/browse/HIVE-16089 Project: Hive Issue Type: Bug Components: JDBC Affects Versions: 1.1.0 Reporter: Sebastian h5. General Story The use case is to connect via the Apache Hive JDBC driver to a Hive where SSL encryption is enabled. It was required to set the ssl-trust store password property {{trustStorePassword}} in the jdbc connection url. If the property is passed via "properties" parameter into {{Driver.connect(url, properties)}} this will not recognized. h5. Suggested Behavior The property {{trustStorePassword}} could be part of the "properties" parameter. This way the password is not part of the JDBC connection url. h5. Acceptance Criteria The ssl trust store password should not be logged as part of the JDBC connection string. Support the trust store password via the properties parameter within connect. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HIVE-4598) Incorrect results when using subquery in multi table insert
[ https://issues.apache.org/jira/browse/HIVE-4598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13666114#comment-13666114 ] Sebastian commented on HIVE-4598: - Another odd result in context of subqueries/views I assume is related: > SELECT max(daily_signups) FROM temp_aggrusers result = 2 temp_aggrusers is a view > CREATE TABLE temp_aggrusers_mat AS SELECT * FROM temp_aggrusers > SELECT max(daily_signups) FROM temp_aggrusers_mat result = 1200 Needless to say 1200 is the correct result. The table has 113000 entries, I haven't been able to reproduce this with a minimal sample. Is there something I'm missing or is this a massive bug? > Incorrect results when using subquery in multi table insert > --- > > Key: HIVE-4598 > URL: https://issues.apache.org/jira/browse/HIVE-4598 > Project: Hive > Issue Type: Bug > Components: Query Processor >Affects Versions: 0.10.0, 0.11.0 >Reporter: Sebastian > > I'm using a multi table insert like this: > FROM > INSERT INTO TABLE t PARTITION (type='x') > SELECT * WHERE type='x' > INSERT INTO TABLE t PARTITION (type='y') > SELECT * WHERE type='y'; > Now when is the name of a table, everything works as expected. > However if I use a subquery as , the query runs but it inserts all results > from the subquery into each partition, as if there were no "WHERE" clauses in > the selects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HIVE-4598) Incorrect results when using subquery in multi table insert
[ https://issues.apache.org/jira/browse/HIVE-4598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian updated HIVE-4598: Affects Version/s: 0.10.0 > Incorrect results when using subquery in multi table insert > --- > > Key: HIVE-4598 > URL: https://issues.apache.org/jira/browse/HIVE-4598 > Project: Hive > Issue Type: Bug > Components: Query Processor >Affects Versions: 0.10.0, 0.11.0 >Reporter: Sebastian > > I'm using a multi table insert like this: > FROM > INSERT INTO TABLE t PARTITION (type='x') > SELECT * WHERE type='x' > INSERT INTO TABLE t PARTITION (type='y') > SELECT * WHERE type='y'; > Now when is the name of a table, everything works as expected. > However if I use a subquery as , the query runs but it inserts all results > from the subquery into each partition, as if there were no "WHERE" clauses in > the selects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HIVE-4598) Incorrect results when using subquery in multi table insert
[ https://issues.apache.org/jira/browse/HIVE-4598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13665218#comment-13665218 ] Sebastian commented on HIVE-4598: - The same problem exists when is a view. > Incorrect results when using subquery in multi table insert > --- > > Key: HIVE-4598 > URL: https://issues.apache.org/jira/browse/HIVE-4598 > Project: Hive > Issue Type: Bug > Components: Query Processor >Affects Versions: 0.11.0 >Reporter: Sebastian > > I'm using a multi table insert like this: > FROM > INSERT INTO TABLE t PARTITION (type='x') > SELECT * WHERE type='x' > INSERT INTO TABLE t PARTITION (type='y') > SELECT * WHERE type='y'; > Now when is the name of a table, everything works as expected. > However if I use a subquery as , the query runs but it inserts all results > from the subquery into each partition, as if there were no "WHERE" clauses in > the selects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HIVE-4598) Incorrect results when using subquery in multi table insert
Sebastian created HIVE-4598: --- Summary: Incorrect results when using subquery in multi table insert Key: HIVE-4598 URL: https://issues.apache.org/jira/browse/HIVE-4598 Project: Hive Issue Type: Bug Components: Query Processor Affects Versions: 0.11.0 Reporter: Sebastian I'm using a multi table insert like this: FROM INSERT INTO TABLE t PARTITION (type='x') SELECT * WHERE type='x' INSERT INTO TABLE t PARTITION (type='y') SELECT * WHERE type='y'; Now when is the name of a table, everything works as expected. However if I use a subquery as , the query runs but it inserts all results from the subquery into each partition, as if there were no "WHERE" clauses in the selects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira