[jira] [Updated] (HIVE-25601) HiveServer2 should support multiple authentication types at the same time
[ https://issues.apache.org/jira/browse/HIVE-25601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25601: -- Description: HiveServer2 should support one or more authentication types at the same time, from the allowed authentication types [ "NOSASL", "LDAP", "KERBEROS", "PAM", "CUSTOM", "SAML" ]. We should not allow "NONE" as an option, when HS2 is configured in multi-authentication mode. HS2 client should have the flexibility of deciding which authentication type to use in the ODBC or JDBC connection string . was: HiveServer2 should support one or more authentication types from the allowed authentication types [ "NOSASL", "LDAP", "KERBEROS", "PAM", "CUSTOM", "SAML" ] at the same time. We should not allow "NONE" as an option, when HS2 is configured in multi-authentication mode. HS2 client should have the flexibility of deciding which authentication type to use in the ODBC or JDBC connection string . > HiveServer2 should support multiple authentication types at the same time > - > > Key: HIVE-25601 > URL: https://issues.apache.org/jira/browse/HIVE-25601 > Project: Hive > Issue Type: Bug >Reporter: Kishen Das >Priority: Major > > HiveServer2 should support one or more authentication types at the same time, > from the allowed authentication types [ "NOSASL", "LDAP", "KERBEROS", "PAM", > "CUSTOM", "SAML" ]. > We should not allow "NONE" as an option, when HS2 is configured in > multi-authentication mode. > HS2 client should have the flexibility of deciding which authentication type > to use in the ODBC or JDBC connection string . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-25601) HiveServer2 should support multiple authentication types at the same time
[ https://issues.apache.org/jira/browse/HIVE-25601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25601: -- Description: HiveServer2 should support one or more authentication types from the allowed authentication types [ "NOSASL", "LDAP", "KERBEROS", "PAM", "CUSTOM", "SAML" ] at the same time. We should not allow "NONE" as an option, when HS2 is configured in multi-authentication mode. HS2 client should have the flexibility of deciding which authentication type to use in the ODBC or JDBC connection string . was: HiveServer2 should support one or more authentication types from the allowed authentication types [ "NOSASL", "NONE", "LDAP", "KERBEROS", "PAM", "CUSTOM", "SAML" ] at the same time. HS2 client should have the flexibility of deciding which authentication type to use in the ODBC or JDBC connection string . > HiveServer2 should support multiple authentication types at the same time > - > > Key: HIVE-25601 > URL: https://issues.apache.org/jira/browse/HIVE-25601 > Project: Hive > Issue Type: Bug >Reporter: Kishen Das >Priority: Major > > HiveServer2 should support one or more authentication types from the allowed > authentication types [ "NOSASL", "LDAP", "KERBEROS", "PAM", "CUSTOM", "SAML" > ] at the same time. > We should not allow "NONE" as an option, when HS2 is configured in > multi-authentication mode. > HS2 client should have the flexibility of deciding which authentication type > to use in the ODBC or JDBC connection string . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-25601) HiveServer2 should support multiple authentication types at the same time
[ https://issues.apache.org/jira/browse/HIVE-25601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425880#comment-17425880 ] Kishen Das commented on HIVE-25601: --- Previously we had a similar ticket -> https://issues.apache.org/jira/browse/HIVE-8554 , but that only handled Kerberos(GSSAPI) and Delegation token(DIGEST) at the same time. This ticket should ideally handle all of possible authentication types at the same time. > HiveServer2 should support multiple authentication types at the same time > - > > Key: HIVE-25601 > URL: https://issues.apache.org/jira/browse/HIVE-25601 > Project: Hive > Issue Type: Bug >Reporter: Kishen Das >Priority: Major > > HiveServer2 should support one or more authentication types from the allowed > authentication types [ "NOSASL", "NONE", "LDAP", "KERBEROS", "PAM", "CUSTOM", > "SAML" ] at the same time. > HS2 client should have the flexibility of deciding which authentication type > to use in the ODBC or JDBC connection string . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HIVE-8554) Hive Server 2 should support multiple authentication types at the same time
[ https://issues.apache.org/jira/browse/HIVE-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das resolved HIVE-8554. -- Resolution: Duplicate > Hive Server 2 should support multiple authentication types at the same time > --- > > Key: HIVE-8554 > URL: https://issues.apache.org/jira/browse/HIVE-8554 > Project: Hive > Issue Type: Bug >Reporter: Joey Echeverria >Priority: Major > > It's very common for clusters to use LDAP/Active Directory as an identity > provider for a cluster while using Kerberos authentication. It would be > useful if users could seamlessly switch between using LDAP username/password > authentication and Kerberos authentication without having to run multiple > Hive Server 2 instances. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (HIVE-8554) Hive Server 2 should support multiple authentication types at the same time
[ https://issues.apache.org/jira/browse/HIVE-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reopened HIVE-8554: -- > Hive Server 2 should support multiple authentication types at the same time > --- > > Key: HIVE-8554 > URL: https://issues.apache.org/jira/browse/HIVE-8554 > Project: Hive > Issue Type: Bug >Reporter: Joey Echeverria >Priority: Major > > It's very common for clusters to use LDAP/Active Directory as an identity > provider for a cluster while using Kerberos authentication. It would be > useful if users could seamlessly switch between using LDAP username/password > authentication and Kerberos authentication without having to run multiple > Hive Server 2 instances. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-25372) [Hive] Advance write ID for remaining DDLs
[ https://issues.apache.org/jira/browse/HIVE-25372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405326#comment-17405326 ] Kishen Das commented on HIVE-25372: --- Rest of DDLs will be addressed as part of https://issues.apache.org/jira/browse/HIVE-25407 > [Hive] Advance write ID for remaining DDLs > -- > > Key: HIVE-25372 > URL: https://issues.apache.org/jira/browse/HIVE-25372 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > We guarantee data consistency for table metadata, when serving data from the > HMS cache. HMS cache relies on Valid Write IDs to decide whether to serve > from cache or refresh from the backing DB and serve, so we have to ensure we > advance write IDs during all alter table flows. We have to ensure we advance > the write ID for below DDLs. > AlterTableSetOwnerAnalyzer.java > -AlterTableSkewedByAnalyzer.java- > AlterTableSetSerdeAnalyzer.java > AlterTableSetSerdePropsAnalyzer.java > -AlterTableUnsetSerdePropsAnalyzer.java- > AlterTableSetPartitionSpecAnalyzer > AlterTableClusterSortAnalyzer.java > AlterTableIntoBucketsAnalyzer.java > AlterTableConcatenateAnalyzer.java > -AlterTableCompactAnalyzer.java- > AlterTableSetFileFormatAnalyzer.java > -AlterTableSetSkewedLocationAnalyzer.java- -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-25407) Advance Write ID during ALTER TABLE ( NOT SKEWED, SKEWED BY, SET SKEWED LOCATION, UNSET SERDEPROPERTIES)
[ https://issues.apache.org/jira/browse/HIVE-25407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25407: -- Summary: Advance Write ID during ALTER TABLE ( NOT SKEWED, SKEWED BY, SET SKEWED LOCATION, UNSET SERDEPROPERTIES) (was: Advance Write ID during ALTER TABLE ( NOT SKEWED, UNSET SERDEPROPERTIES) > Advance Write ID during ALTER TABLE ( NOT SKEWED, SKEWED BY, SET SKEWED > LOCATION, UNSET SERDEPROPERTIES) > > > Key: HIVE-25407 > URL: https://issues.apache.org/jira/browse/HIVE-25407 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Below DDLs should be investigated separately on why the advancing the write > ID is not working for transactional tables, even after adding the logic to > advance the write ID. > * -ALTER TABLE SET PARTITION SPEC- > * ALTER TABLE UNSET SERDEPROPERTIES > * ALTER TABLE NOT SKEWED > * -ALTER TABLE COMPACT- > * ALTER TABLE SKEWED BY > * ALTER TABLE SET SKEWED LOCATION -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-25407) Advance Write ID during ALTER TABLE ( NOT SKEWED, UNSET SERDEPROPERTIES
[ https://issues.apache.org/jira/browse/HIVE-25407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25407: -- Summary: Advance Write ID during ALTER TABLE ( NOT SKEWED, UNSET SERDEPROPERTIES (was: Advance Write ID during ALTER TABLE ( UNSET SERDEPROPERTIES) > Advance Write ID during ALTER TABLE ( NOT SKEWED, UNSET SERDEPROPERTIES > --- > > Key: HIVE-25407 > URL: https://issues.apache.org/jira/browse/HIVE-25407 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Below DDLs should be investigated separately on why the advancing the write > ID is not working for transactional tables, even after adding the logic to > advance the write ID. > * -ALTER TABLE SET PARTITION SPEC- > * ALTER TABLE UNSET SERDEPROPERTIES > * ALTER TABLE NOT SKEWED > * -ALTER TABLE COMPACT- > * ALTER TABLE SKEWED BY > * ALTER TABLE SET SKEWED LOCATION -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-25407) Advance Write ID during ALTER TABLE ( UNSET SERDEPROPERTIES
[ https://issues.apache.org/jira/browse/HIVE-25407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25407: -- Summary: Advance Write ID during ALTER TABLE ( UNSET SERDEPROPERTIES (was: [Hive] Investigate why advancing the Write ID not working for some DDLs and fix it, if appropriate) > Advance Write ID during ALTER TABLE ( UNSET SERDEPROPERTIES > --- > > Key: HIVE-25407 > URL: https://issues.apache.org/jira/browse/HIVE-25407 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Below DDLs should be investigated separately on why the advancing the write > ID is not working for transactional tables, even after adding the logic to > advance the write ID. > * -ALTER TABLE SET PARTITION SPEC- > * ALTER TABLE UNSET SERDEPROPERTIES > * ALTER TABLE NOT SKEWED > * -ALTER TABLE COMPACT- > * ALTER TABLE SKEWED BY > * ALTER TABLE SET SKEWED LOCATION -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HIVE-25461) Add a test case to ensure Truncate table advances the write ID
[ https://issues.apache.org/jira/browse/HIVE-25461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HIVE-25461 started by Kishen Das. - > Add a test case to ensure Truncate table advances the write ID > -- > > Key: HIVE-25461 > URL: https://issues.apache.org/jira/browse/HIVE-25461 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-25461) Add a test case to ensure Truncate table advances the write ID
[ https://issues.apache.org/jira/browse/HIVE-25461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-25461: - Assignee: Kishen Das > Add a test case to ensure Truncate table advances the write ID > -- > > Key: HIVE-25461 > URL: https://issues.apache.org/jira/browse/HIVE-25461 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-25461) Add a test case to ensure Truncate table advances the write ID
[ https://issues.apache.org/jira/browse/HIVE-25461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25461: -- Summary: Add a test case to ensure Truncate table advances the write ID (was: Truncate table should advance the write ID) > Add a test case to ensure Truncate table advances the write ID > -- > > Key: HIVE-25461 > URL: https://issues.apache.org/jira/browse/HIVE-25461 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-25372) [Hive] Advance write ID for remaining DDLs
[ https://issues.apache.org/jira/browse/HIVE-25372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25372: -- Description: We guarantee data consistency for table metadata, when serving data from the HMS cache. HMS cache relies on Valid Write IDs to decide whether to serve from cache or refresh from the backing DB and serve, so we have to ensure we advance write IDs during all alter table flows. We have to ensure we advance the write ID for below DDLs. AlterTableSetOwnerAnalyzer.java -AlterTableSkewedByAnalyzer.java- AlterTableSetSerdeAnalyzer.java AlterTableSetSerdePropsAnalyzer.java -AlterTableUnsetSerdePropsAnalyzer.java- AlterTableSetPartitionSpecAnalyzer AlterTableClusterSortAnalyzer.java AlterTableIntoBucketsAnalyzer.java AlterTableConcatenateAnalyzer.java -AlterTableCompactAnalyzer.java- AlterTableSetFileFormatAnalyzer.java -AlterTableSetSkewedLocationAnalyzer.java- was: We guarantee data consistency for table metadata, when serving data from the HMS cache. HMS cache relies on Valid Write IDs to decide whether to serve from cache or refresh from the backing DB and serve, so we have to ensure we advance write IDs during all alter table flows. We have to ensure we advance the write ID for below DDLs. AlterTableSetOwnerAnalyzer.java AlterTableSkewedByAnalyzer.java AlterTableSetSerdeAnalyzer.java AlterTableSetSerdePropsAnalyzer.java AlterTableUnsetSerdePropsAnalyzer.java AlterTableSetPartitionSpecAnalyzer AlterTableClusterSortAnalyzer.java AlterTableIntoBucketsAnalyzer.java AlterTableConcatenateAnalyzer.java AlterTableCompactAnalyzer.java AlterTableSetFileFormatAnalyzer.java AlterTableSetSkewedLocationAnalyzer.java > [Hive] Advance write ID for remaining DDLs > -- > > Key: HIVE-25372 > URL: https://issues.apache.org/jira/browse/HIVE-25372 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > We guarantee data consistency for table metadata, when serving data from the > HMS cache. HMS cache relies on Valid Write IDs to decide whether to serve > from cache or refresh from the backing DB and serve, so we have to ensure we > advance write IDs during all alter table flows. We have to ensure we advance > the write ID for below DDLs. > AlterTableSetOwnerAnalyzer.java > -AlterTableSkewedByAnalyzer.java- > AlterTableSetSerdeAnalyzer.java > AlterTableSetSerdePropsAnalyzer.java > -AlterTableUnsetSerdePropsAnalyzer.java- > AlterTableSetPartitionSpecAnalyzer > AlterTableClusterSortAnalyzer.java > AlterTableIntoBucketsAnalyzer.java > AlterTableConcatenateAnalyzer.java > -AlterTableCompactAnalyzer.java- > AlterTableSetFileFormatAnalyzer.java > -AlterTableSetSkewedLocationAnalyzer.java- -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HIVE-25460) Future ALTER TABLE flows should advance write Id for transactional table
[ https://issues.apache.org/jira/browse/HIVE-25460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HIVE-25460 started by Kishen Das. - > Future ALTER TABLE flows should advance write Id for transactional table > > > Key: HIVE-25460 > URL: https://issues.apache.org/jira/browse/HIVE-25460 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Future ALTER TABLE flows should advance write Id for transactional table. > This is required so that HMS cache can provide strong consistency, while > serving the metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-25460) Future ALTER TABLE flows should advance write Id for transactional table
[ https://issues.apache.org/jira/browse/HIVE-25460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-25460: - Assignee: Kishen Das > Future ALTER TABLE flows should advance write Id for transactional table > > > Key: HIVE-25460 > URL: https://issues.apache.org/jira/browse/HIVE-25460 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Future ALTER TABLE flows should advance write Id for transactional table. > This is required so that HMS cache can provide strong consistency, while > serving the metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-25407) [Hive] Investigate why advancing the Write ID not working for some DDLs and fix it, if appropriate
[ https://issues.apache.org/jira/browse/HIVE-25407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25407: -- Description: Below DDLs should be investigated separately on why the advancing the write ID is not working for transactional tables, even after adding the logic to advance the write ID. * -ALTER TABLE SET PARTITION SPEC- * ALTER TABLE UNSET SERDEPROPERTIES * ALTER TABLE NOT SKEWED * -ALTER TABLE COMPACT- * ALTER TABLE SKEWED BY * ALTER TABLE SET SKEWED LOCATION was: Below DDLs should be investigated separately on why the advancing the write ID is not working for transactional tables, even after adding the logic to advance the write ID. * -ALTER TABLE SET PARTITION SPEC- * ALTER TABLE UNSET SERDEPROPERTIES * -ALTER TABLE COMPACT- * ALTER TABLE SKEWED BY * ALTER TABLE SET SKEWED LOCATION > [Hive] Investigate why advancing the Write ID not working for some DDLs and > fix it, if appropriate > -- > > Key: HIVE-25407 > URL: https://issues.apache.org/jira/browse/HIVE-25407 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Below DDLs should be investigated separately on why the advancing the write > ID is not working for transactional tables, even after adding the logic to > advance the write ID. > * -ALTER TABLE SET PARTITION SPEC- > * ALTER TABLE UNSET SERDEPROPERTIES > * ALTER TABLE NOT SKEWED > * -ALTER TABLE COMPACT- > * ALTER TABLE SKEWED BY > * ALTER TABLE SET SKEWED LOCATION -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-25407) [Hive] Investigate why advancing the Write ID not working for some DDLs and fix it, if appropriate
[ https://issues.apache.org/jira/browse/HIVE-25407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17403339#comment-17403339 ] Kishen Das commented on HIVE-25407: --- As per https://issues.apache.org/jira/browse/HIVE-25234 * ALTER TABLE SET PARTITION SPEC is for Iceberg partitioning and Iceberg is only supported for external tables. So, we can skip it for now, as we only have to advance the write Id for DDLs that support transaction tables. > [Hive] Investigate why advancing the Write ID not working for some DDLs and > fix it, if appropriate > -- > > Key: HIVE-25407 > URL: https://issues.apache.org/jira/browse/HIVE-25407 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Below DDLs should be investigated separately on why the advancing the write > ID is not working for transactional tables, even after adding the logic to > advance the write ID. > * -ALTER TABLE SET PARTITION SPEC- > * ALTER TABLE UNSET SERDEPROPERTIES > * -ALTER TABLE COMPACT- > * ALTER TABLE SKEWED BY > * ALTER TABLE SET SKEWED LOCATION -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-25407) [Hive] Investigate why advancing the Write ID not working for some DDLs and fix it, if appropriate
[ https://issues.apache.org/jira/browse/HIVE-25407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25407: -- Description: Below DDLs should be investigated separately on why the advancing the write ID is not working for transactional tables, even after adding the logic to advance the write ID. * -ALTER TABLE SET PARTITION SPEC- * ALTER TABLE UNSET SERDEPROPERTIES * -ALTER TABLE COMPACT- * ALTER TABLE SKEWED BY * ALTER TABLE SET SKEWED LOCATION was: Below DDLs should be investigated separately on why the advancing the write ID is not working for transactional tables, even after adding the logic to advance the write ID. * ALTER TABLE SET PARTITION SPEC * ALTER TABLE UNSET SERDEPROPERTIES * -ALTER TABLE COMPACT- * ALTER TABLE SKEWED BY * ALTER TABLE SET SKEWED LOCATION > [Hive] Investigate why advancing the Write ID not working for some DDLs and > fix it, if appropriate > -- > > Key: HIVE-25407 > URL: https://issues.apache.org/jira/browse/HIVE-25407 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Below DDLs should be investigated separately on why the advancing the write > ID is not working for transactional tables, even after adding the logic to > advance the write ID. > * -ALTER TABLE SET PARTITION SPEC- > * ALTER TABLE UNSET SERDEPROPERTIES > * -ALTER TABLE COMPACT- > * ALTER TABLE SKEWED BY > * ALTER TABLE SET SKEWED LOCATION -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-25407) [Hive] Investigate why advancing the Write ID not working for some DDLs and fix it, if appropriate
[ https://issues.apache.org/jira/browse/HIVE-25407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-25407: - Assignee: Kishen Das > [Hive] Investigate why advancing the Write ID not working for some DDLs and > fix it, if appropriate > -- > > Key: HIVE-25407 > URL: https://issues.apache.org/jira/browse/HIVE-25407 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Below DDLs should be investigated separately on why the advancing the write > ID is not working for transactional tables, even after adding the logic to > advance the write ID. > * ALTER TABLE SET PARTITION SPEC > * ALTER TABLE UNSET SERDEPROPERTIES > * -ALTER TABLE COMPACT- > * ALTER TABLE SKEWED BY > * ALTER TABLE SET SKEWED LOCATION -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HIVE-25407) [Hive] Investigate why advancing the Write ID not working for some DDLs and fix it, if appropriate
[ https://issues.apache.org/jira/browse/HIVE-25407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HIVE-25407 started by Kishen Das. - > [Hive] Investigate why advancing the Write ID not working for some DDLs and > fix it, if appropriate > -- > > Key: HIVE-25407 > URL: https://issues.apache.org/jira/browse/HIVE-25407 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Below DDLs should be investigated separately on why the advancing the write > ID is not working for transactional tables, even after adding the logic to > advance the write ID. > * ALTER TABLE SET PARTITION SPEC > * ALTER TABLE UNSET SERDEPROPERTIES > * -ALTER TABLE COMPACT- > * ALTER TABLE SKEWED BY > * ALTER TABLE SET SKEWED LOCATION -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HIVE-25372) [Hive] Advance write ID for remaining DDLs
[ https://issues.apache.org/jira/browse/HIVE-25372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das resolved HIVE-25372. --- Resolution: Fixed > [Hive] Advance write ID for remaining DDLs > -- > > Key: HIVE-25372 > URL: https://issues.apache.org/jira/browse/HIVE-25372 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > We guarantee data consistency for table metadata, when serving data from the > HMS cache. HMS cache relies on Valid Write IDs to decide whether to serve > from cache or refresh from the backing DB and serve, so we have to ensure we > advance write IDs during all alter table flows. We have to ensure we advance > the write ID for below DDLs. > AlterTableSetOwnerAnalyzer.java > AlterTableSkewedByAnalyzer.java > AlterTableSetSerdeAnalyzer.java > AlterTableSetSerdePropsAnalyzer.java > AlterTableUnsetSerdePropsAnalyzer.java > AlterTableSetPartitionSpecAnalyzer > AlterTableClusterSortAnalyzer.java > AlterTableIntoBucketsAnalyzer.java > AlterTableConcatenateAnalyzer.java > AlterTableCompactAnalyzer.java > AlterTableSetFileFormatAnalyzer.java > AlterTableSetSkewedLocationAnalyzer.java -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-25407) [Hive] Investigate why advancing the Write ID not working for some DDLs and fix it, if appropriate
[ https://issues.apache.org/jira/browse/HIVE-25407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17391692#comment-17391692 ] Kishen Das commented on HIVE-25407: --- [~pvary] Sounds good. We already compare the latest compaction ID to figure out if there was any recent compaction, before serving file metadata. So, we are good. Cc : [~klcopp] > [Hive] Investigate why advancing the Write ID not working for some DDLs and > fix it, if appropriate > -- > > Key: HIVE-25407 > URL: https://issues.apache.org/jira/browse/HIVE-25407 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Priority: Major > > Below DDLs should be investigated separately on why the advancing the write > ID is not working for transactional tables, even after adding the logic to > advance the write ID. > * ALTER TABLE SET PARTITION SPEC > * ALTER TABLE UNSET SERDEPROPERTIES > * -ALTER TABLE COMPACT- > * ALTER TABLE SKEWED BY > * ALTER TABLE SET SKEWED LOCATION -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-25407) [Hive] Investigate why advancing the Write ID not working for some DDLs and fix it, if appropriate
[ https://issues.apache.org/jira/browse/HIVE-25407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25407: -- Description: Below DDLs should be investigated separately on why the advancing the write ID is not working for transactional tables, even after adding the logic to advance the write ID. * ALTER TABLE SET PARTITION SPEC * ALTER TABLE UNSET SERDEPROPERTIES * -ALTER TABLE COMPACT- * ALTER TABLE SKEWED BY * ALTER TABLE SET SKEWED LOCATION was: Below DDLs should be investigated separately on why the advancing the write ID is not working for transactional tables, even after adding the logic to advance the write ID. * ALTER TABLE SET PARTITION SPEC * ALTER TABLE UNSET SERDEPROPERTIES * ALTER TABLE COMPACT * ALTER TABLE SKEWED BY * ALTER TABLE SET SKEWED LOCATION > [Hive] Investigate why advancing the Write ID not working for some DDLs and > fix it, if appropriate > -- > > Key: HIVE-25407 > URL: https://issues.apache.org/jira/browse/HIVE-25407 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Priority: Major > > Below DDLs should be investigated separately on why the advancing the write > ID is not working for transactional tables, even after adding the logic to > advance the write ID. > * ALTER TABLE SET PARTITION SPEC > * ALTER TABLE UNSET SERDEPROPERTIES > * -ALTER TABLE COMPACT- > * ALTER TABLE SKEWED BY > * ALTER TABLE SET SKEWED LOCATION -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-25407) [Hive] Investigate why advancing the Write ID not working for some DDLs and fix it, if appropriate
[ https://issues.apache.org/jira/browse/HIVE-25407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25407: -- Summary: [Hive] Investigate why advancing the Write ID not working for some DDLs and fix it, if appropriate (was: Advance Write ID for remaining DDLs) > [Hive] Investigate why advancing the Write ID not working for some DDLs and > fix it, if appropriate > -- > > Key: HIVE-25407 > URL: https://issues.apache.org/jira/browse/HIVE-25407 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Priority: Major > > Below DDLs should be investigated separately on why the advancing the write > ID is not working for transactional tables, even after adding the logic to > advance the write ID. > * ALTER TABLE SET PARTITION SPEC > * ALTER TABLE UNSET SERDEPROPERTIES > * ALTER TABLE COMPACT > * ALTER TABLE SKEWED BY > * ALTER TABLE SET SKEWED LOCATION -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-25372) [Hive] Advance write ID for remaining DDLs
[ https://issues.apache.org/jira/browse/HIVE-25372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17386414#comment-17386414 ] Kishen Das commented on HIVE-25372: --- [https://github.com/apache/hive/pull/2524] > [Hive] Advance write ID for remaining DDLs > -- > > Key: HIVE-25372 > URL: https://issues.apache.org/jira/browse/HIVE-25372 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > We guarantee data consistency for table metadata, when serving data from the > HMS cache. HMS cache relies on Valid Write IDs to decide whether to serve > from cache or refresh from the backing DB and serve, so we have to ensure we > advance write IDs during all alter table flows. We have to ensure we advance > the write ID for below DDLs. > AlterTableSetOwnerAnalyzer.java > AlterTableSkewedByAnalyzer.java > AlterTableSetSerdeAnalyzer.java > AlterTableSetSerdePropsAnalyzer.java > AlterTableUnsetSerdePropsAnalyzer.java > AlterTableSetPartitionSpecAnalyzer > AlterTableClusterSortAnalyzer.java > AlterTableIntoBucketsAnalyzer.java > AlterTableConcatenateAnalyzer.java > AlterTableCompactAnalyzer.java > AlterTableSetFileFormatAnalyzer.java > AlterTableSetSkewedLocationAnalyzer.java -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HIVE-25372) [Hive] Advance write ID for remaining DDLs
[ https://issues.apache.org/jira/browse/HIVE-25372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HIVE-25372 started by Kishen Das. - > [Hive] Advance write ID for remaining DDLs > -- > > Key: HIVE-25372 > URL: https://issues.apache.org/jira/browse/HIVE-25372 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > We guarantee data consistency for table metadata, when serving data from the > HMS cache. HMS cache relies on Valid Write IDs to decide whether to serve > from cache or refresh from the backing DB and serve, so we have to ensure we > advance write IDs during all alter table flows. We have to ensure we advance > the write ID for below DDLs. > AlterTableSetOwnerAnalyzer.java > AlterTableSkewedByAnalyzer.java > AlterTableSetSerdeAnalyzer.java > AlterTableSetSerdePropsAnalyzer.java > AlterTableUnsetSerdePropsAnalyzer.java > AlterTableSetPartitionSpecAnalyzer > AlterTableClusterSortAnalyzer.java > AlterTableIntoBucketsAnalyzer.java > AlterTableConcatenateAnalyzer.java > AlterTableCompactAnalyzer.java > AlterTableSetFileFormatAnalyzer.java > AlterTableSetSkewedLocationAnalyzer.java -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-25321) [HMS] Advance write Id during AlterTableDropPartition
[ https://issues.apache.org/jira/browse/HIVE-25321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17385653#comment-17385653 ] Kishen Das commented on HIVE-25321: --- AlterTableExchangePartition is not supported right now for transactional tables, so we will not advance write ID for that. > [HMS] Advance write Id during AlterTableDropPartition > - > > Key: HIVE-25321 > URL: https://issues.apache.org/jira/browse/HIVE-25321 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > All DDLs should advance the write ID, so that we can provide consistent data > from the cache, based on the validWriteIds. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-25321) [HMS] Advance write Id during AlterTableDropPartition
[ https://issues.apache.org/jira/browse/HIVE-25321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25321: -- Summary: [HMS] Advance write Id during AlterTableDropPartition (was: [HMS] Advance write Id during AlterTableDropPartition and AlterTableExchangePartition) > [HMS] Advance write Id during AlterTableDropPartition > - > > Key: HIVE-25321 > URL: https://issues.apache.org/jira/browse/HIVE-25321 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > All DDLs should advance the write ID, so that we can provide consistent data > from the cache, based on the validWriteIds. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-25372) [Hive] Advance write ID for remaining DDLs
[ https://issues.apache.org/jira/browse/HIVE-25372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-25372: - > [Hive] Advance write ID for remaining DDLs > -- > > Key: HIVE-25372 > URL: https://issues.apache.org/jira/browse/HIVE-25372 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > We guarantee data consistency for table metadata, when serving data from the > HMS cache. HMS cache relies on Valid Write IDs to decide whether to serve > from cache or refresh from the backing DB and serve, so we have to ensure we > advance write IDs during all alter table flows. We have to ensure we advance > the write ID for below DDLs. > AlterTableSetOwnerAnalyzer.java > AlterTableSkewedByAnalyzer.java > AlterTableSetSerdeAnalyzer.java > AlterTableSetSerdePropsAnalyzer.java > AlterTableUnsetSerdePropsAnalyzer.java > AlterTableSetPartitionSpecAnalyzer > AlterTableClusterSortAnalyzer.java > AlterTableIntoBucketsAnalyzer.java > AlterTableConcatenateAnalyzer.java > AlterTableCompactAnalyzer.java > AlterTableSetFileFormatAnalyzer.java > AlterTableSetSkewedLocationAnalyzer.java -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-25321) [HMS] Advance write Id during AlterTableDropPartition and AlterTableExchangePartition
[ https://issues.apache.org/jira/browse/HIVE-25321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25321: -- Summary: [HMS] Advance write Id during AlterTableDropPartition and AlterTableExchangePartition (was: [HMS] Advance write Id during AlterTableDropPartition ) > [HMS] Advance write Id during AlterTableDropPartition and > AlterTableExchangePartition > - > > Key: HIVE-25321 > URL: https://issues.apache.org/jira/browse/HIVE-25321 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > All DDLs should advance the write ID, so that we can provide consistent data > from the cache, based on the validWriteIds. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-25321) [HMS] Advance write Id during AlterTableDropPartition
[ https://issues.apache.org/jira/browse/HIVE-25321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25321: -- Summary: [HMS] Advance write Id during AlterTableDropPartition (was: [HMS] Alter table drop partition doesn't advance Write ID) > [HMS] Advance write Id during AlterTableDropPartition > -- > > Key: HIVE-25321 > URL: https://issues.apache.org/jira/browse/HIVE-25321 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > All DDLs should advance the write ID, so that we can provide consistent data > from the cache, based on the validWriteIds. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HIVE-25321) [HMS] Alter table drop partition doesn't advance Write ID
[ https://issues.apache.org/jira/browse/HIVE-25321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HIVE-25321 started by Kishen Das. - > [HMS] Alter table drop partition doesn't advance Write ID > - > > Key: HIVE-25321 > URL: https://issues.apache.org/jira/browse/HIVE-25321 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > All DDLs should advance the write ID, so that we can provide consistent data > from the cache, based on the validWriteIds. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-25321) [HMS] Alter table drop partition doesn't advance Write ID
[ https://issues.apache.org/jira/browse/HIVE-25321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-25321: - Assignee: Kishen Das > [HMS] Alter table drop partition doesn't advance Write ID > - > > Key: HIVE-25321 > URL: https://issues.apache.org/jira/browse/HIVE-25321 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > All DDLs should advance the write ID, so that we can provide consistent data > from the cache, based on the validWriteIds. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-25130) alter table concat gives NullPointerException, when data is inserted from Spark
[ https://issues.apache.org/jira/browse/HIVE-25130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-25130: - Assignee: Kishen Das > alter table concat gives NullPointerException, when data is inserted from > Spark > --- > > Key: HIVE-25130 > URL: https://issues.apache.org/jira/browse/HIVE-25130 > Project: Hive > Issue Type: Bug >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > This is the complete stack trace of the NullPointerException > 2021-03-01 14:50:32,201 ERROR org.apache.hadoop.hive.ql.exec.Task: > [HiveServer2-Background-Pool: Thread-76760]: Job Commit failed with exception > 'java.lang.NullPointerException(null)' > java.lang.NullPointerException > at > org.apache.hadoop.hive.ql.exec.Utilities.getAttemptIdFromFilename(Utilities.java:1333) > at > org.apache.hadoop.hive.ql.exec.Utilities.compareTempOrDuplicateFiles(Utilities.java:1966) > at > org.apache.hadoop.hive.ql.exec.Utilities.ponderRemovingTempOrDuplicateFile(Utilities.java:1907) > at > org.apache.hadoop.hive.ql.exec.Utilities.removeTempOrDuplicateFilesNonMm(Utilities.java:1892) > at > org.apache.hadoop.hive.ql.exec.Utilities.removeTempOrDuplicateFiles(Utilities.java:1797) > at > org.apache.hadoop.hive.ql.exec.Utilities.removeTempOrDuplicateFiles(Utilities.java:1674) > at > org.apache.hadoop.hive.ql.exec.Utilities.mvFileToFinalPath(Utilities.java:1544) > at > org.apache.hadoop.hive.ql.exec.AbstractFileMergeOperator.jobCloseOp(AbstractFileMergeOperator.java:304) > at org.apache.hadoop.hive.ql.exec.Operator.jobClose(Operator.java:798) > at org.apache.hadoop.hive.ql.exec.tez.TezTask.close(TezTask.java:637) > at org.apache.hadoop.hive.ql.exec.tez.TezTask.execute(TezTask.java:335) > at > org.apache.hadoop.hive.ql.ddl.table.storage.concatenate.AlterTableConcatenateOperation.executeTask(AlterTableConcatenateOperation.java:129) > at > org.apache.hadoop.hive.ql.ddl.table.storage.concatenate.AlterTableConcatenateOperation.execute(AlterTableConcatenateOperation.java:63) > at org.apache.hadoop.hive.ql.ddl.DDLTask.execute(DDLTask.java:80) > at org.apache.hadoop.hive.ql.exec.Task.executeTask(Task.java:213) > at > org.apache.hadoop.hive.ql.exec.TaskRunner.runSequential(TaskRunner.java:105) > at org.apache.hadoop.hive.ql.Executor.launchTask(Executor.java:357) > at org.apache.hadoop.hive.ql.Executor.launchTasks(Executor.java:330) > at org.apache.hadoop.hive.ql.Executor.runTasks(Executor.java:246) > at org.apache.hadoop.hive.ql.Executor.execute(Executor.java:109) > at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:740) > at org.apache.hadoop.hive.ql.Driver.run(Driver.java:495) > at org.apache.hadoop.hive.ql.Driver.run(Driver.java:489) > at org.apache.hadoop.hive.ql.reexec.ReExecDriver.run(ReExecDriver.java:166) > at > org.apache.hive.service.cli.operation.SQLOperation.runQuery(SQLOperation.java:225) > at > org.apache.hive.service.cli.operation.SQLOperation.access$700(SQLOperation.java:87) > at > org.apache.hive.service.cli.operation.SQLOperation$BackgroundWork$1.run(SQLOperation.java:322) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at > org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1898) > at > org.apache.hive.service.cli.operation.SQLOperation$BackgroundWork.run(SQLOperation.java:340) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (HIVE-25074) Remove Metastore flushCache usage
[
https://issues.apache.org/jira/browse/HIVE-25074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17342181#comment-17342181
]
Kishen Das edited comment on HIVE-25074 at 5/10/21, 11:02 PM:
--
[~pvary] I did not see any usage of this API in Impala.
was (Author: kishendas):
[~pvary] I don't see any usage of this API in Impala.
> Remove Metastore flushCache usage
> -
>
> Key: HIVE-25074
> URL: https://issues.apache.org/jira/browse/HIVE-25074
> Project: Hive
> Issue Type: Improvement
> Components: Metastore, Standalone Metastore
>Affects Versions: 4.0.0
>Reporter: Miklos Szurap
>Assignee: Zoltan Chovan
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The "flushCache" in HiveMetaStore with the ObjectStore implementation is
> currently a NOOP:
> {code:java}
> public void flushCache() {
> // NOP as there's no caching
> } {code}
> The HBaseStore (HBaseReadWrite) had some logic in it, however it has been
> removed in HIVE-17234.
> As I see the calls are going like this:
> HiveMetaStoreClient.flushCache() -> CachedStore.flushCache() ->
> ObjectStore.flushCache()
> There are significant amount of calls (about 10% of all calls) made from the
> client to the server - to do nothing. We could spare the call to the server
> completely, including getting a DB connection which can take 1+ seconds under
> high load scenarios slowing down Hive queries unnecessarily.
> Can we:
> # Deprecate the RawStore.flushCache (if there are other implementations)
> # Deprecate the HiveMetaStoreClient.flushCache()
> # Do the NOOP on the client side in HiveMetaStoreClient.flushCache() (while
> it is not removed in a next version)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HIVE-25074) Remove Metastore flushCache usage
[
https://issues.apache.org/jira/browse/HIVE-25074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17342181#comment-17342181
]
Kishen Das commented on HIVE-25074:
---
[~pvary] I don't see any usage of this API in Impala.
> Remove Metastore flushCache usage
> -
>
> Key: HIVE-25074
> URL: https://issues.apache.org/jira/browse/HIVE-25074
> Project: Hive
> Issue Type: Improvement
> Components: Metastore, Standalone Metastore
>Affects Versions: 4.0.0
>Reporter: Miklos Szurap
>Assignee: Zoltan Chovan
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The "flushCache" in HiveMetaStore with the ObjectStore implementation is
> currently a NOOP:
> {code:java}
> public void flushCache() {
> // NOP as there's no caching
> } {code}
> The HBaseStore (HBaseReadWrite) had some logic in it, however it has been
> removed in HIVE-17234.
> As I see the calls are going like this:
> HiveMetaStoreClient.flushCache() -> CachedStore.flushCache() ->
> ObjectStore.flushCache()
> There are significant amount of calls (about 10% of all calls) made from the
> client to the server - to do nothing. We could spare the call to the server
> completely, including getting a DB connection which can take 1+ seconds under
> high load scenarios slowing down Hive queries unnecessarily.
> Can we:
> # Deprecate the RawStore.flushCache (if there are other implementations)
> # Deprecate the HiveMetaStoreClient.flushCache()
> # Do the NOOP on the client side in HiveMetaStoreClient.flushCache() (while
> it is not removed in a next version)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HIVE-25005) Provide default implementation for HMS APIs
[ https://issues.apache.org/jira/browse/HIVE-25005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25005: -- Description: If there is a remote cache that implements HMS APIs, it would be useful to have default implementation for all the APIs, so that any new HMS API will not break the build for the remote cache. (was: If there is a remote cache that implements HMS APIs, it would be useful to have dummy implementation for all the APIs, so that any new HMS API will not break the build for the remote cache. ) > Provide default implementation for HMS APIs > > > Key: HIVE-25005 > URL: https://issues.apache.org/jira/browse/HIVE-25005 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > If there is a remote cache that implements HMS APIs, it would be useful to > have default implementation for all the APIs, so that any new HMS API will > not break the build for the remote cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-25005) Provide default implementation for HMS APIs
[ https://issues.apache.org/jira/browse/HIVE-25005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-25005: -- Summary: Provide default implementation for HMS APIs (was: Provide dummy implementation for HMS APIs ) > Provide default implementation for HMS APIs > > > Key: HIVE-25005 > URL: https://issues.apache.org/jira/browse/HIVE-25005 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > If there is a remote cache that implements HMS APIs, it would be useful to > have dummy implementation for all the APIs, so that any new HMS API will not > break the build for the remote cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HIVE-25005) Provide dummy implementation for HMS APIs
[ https://issues.apache.org/jira/browse/HIVE-25005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HIVE-25005 started by Kishen Das. - > Provide dummy implementation for HMS APIs > -- > > Key: HIVE-25005 > URL: https://issues.apache.org/jira/browse/HIVE-25005 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > If there is a remote cache that implements HMS APIs, it would be useful to > have dummy implementation for all the APIs, so that any new HMS API will not > break the build for the remote cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-25005) Provide dummy implementation for HMS APIs
[ https://issues.apache.org/jira/browse/HIVE-25005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-25005: - Assignee: Kishen Das > Provide dummy implementation for HMS APIs > -- > > Key: HIVE-25005 > URL: https://issues.apache.org/jira/browse/HIVE-25005 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > If there is a remote cache that implements HMS APIs, it would be useful to > have dummy implementation for all the APIs, so that any new HMS API will not > break the build for the remote cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HIVE-24794) [HMS] Populate tableId in the response of get_valid_write_ids API
[ https://issues.apache.org/jira/browse/HIVE-24794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das resolved HIVE-24794. --- Resolution: Won't Fix > [HMS] Populate tableId in the response of get_valid_write_ids API > - > > Key: HIVE-24794 > URL: https://issues.apache.org/jira/browse/HIVE-24794 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > In HS2, after query compilation phase, we acquire lock in DriverTxnHandler. > isValidTxnListState and later ensure there are no conflicting transactions by > using driverContext.getTxnManager().getLatestTxnIdInConflict(); . This > doesn't work well, if there are external entities that drop and recreate the > table with the same name. So, we should also make sure the tableId itself is > not changed, after lock has been acquired. This Jira is to enhance > getValidWriteIdList to return tableId as well. Idea is to cache the tableId > in SessionState and later compare it with what getValidWriteIdList returns. > If the table was dropped and recreated, the tableId will not match and we > have to recompile the query. Caching the tableId in SessionState will be done > as part of a separate Jira. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HIVE-24796) [HS2] Enhance DriverTxnHandler.isValidTxnListState logic to include tableId comparison
[ https://issues.apache.org/jira/browse/HIVE-24796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das resolved HIVE-24796. --- Resolution: Won't Fix > [HS2] Enhance DriverTxnHandler.isValidTxnListState logic to include tableId > comparison > -- > > Key: HIVE-24796 > URL: https://issues.apache.org/jira/browse/HIVE-24796 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > In HS2, after query compilation phase, we acquire lock in DriverTxnHandler. > isValidTxnListState and later ensure there are no conflicting transactions by > using driverContext.getTxnManager().getLatestTxnIdInConflict(); . This > doesn't work well, if there are external entities that drop and recreate the > table with the same name. So, we should also make sure the tableId itself is > not changed, after lock has been acquired. This Jira is to enhance the > DriverTxnHandler.isValidTxnListState logic to include tableId comparison. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-24794) [HMS] Populate tableId in the response of get_valid_write_ids API
[ https://issues.apache.org/jira/browse/HIVE-24794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304279#comment-17304279 ] Kishen Das commented on HIVE-24794: --- This would take care of the above issue -> https://issues.apache.org/jira/browse/HIVE-24662 . > [HMS] Populate tableId in the response of get_valid_write_ids API > - > > Key: HIVE-24794 > URL: https://issues.apache.org/jira/browse/HIVE-24794 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > In HS2, after query compilation phase, we acquire lock in DriverTxnHandler. > isValidTxnListState and later ensure there are no conflicting transactions by > using driverContext.getTxnManager().getLatestTxnIdInConflict(); . This > doesn't work well, if there are external entities that drop and recreate the > table with the same name. So, we should also make sure the tableId itself is > not changed, after lock has been acquired. This Jira is to enhance > getValidWriteIdList to return tableId as well. Idea is to cache the tableId > in SessionState and later compare it with what getValidWriteIdList returns. > If the table was dropped and recreated, the tableId will not match and we > have to recompile the query. Caching the tableId in SessionState will be done > as part of a separate Jira. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-24795) [HS2] Cache tableId in SessionState
[ https://issues.apache.org/jira/browse/HIVE-24795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304278#comment-17304278 ] Kishen Das commented on HIVE-24795: --- This would take care of the above issue -> https://issues.apache.org/jira/browse/HIVE-24662 . > [HS2] Cache tableId in SessionState > > > Key: HIVE-24795 > URL: https://issues.apache.org/jira/browse/HIVE-24795 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Please go through https://issues.apache.org/jira/browse/HIVE-24794 to > understand why this is required. Its basically to handle a corner case, in > which a table gets dropped and recreated with the same name, after we gather > information about all the tables and we acquire the lock. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HIVE-24795) [HS2] Cache tableId in SessionState
[ https://issues.apache.org/jira/browse/HIVE-24795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das resolved HIVE-24795. --- Resolution: Won't Fix > [HS2] Cache tableId in SessionState > > > Key: HIVE-24795 > URL: https://issues.apache.org/jira/browse/HIVE-24795 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Please go through https://issues.apache.org/jira/browse/HIVE-24794 to > understand why this is required. Its basically to handle a corner case, in > which a table gets dropped and recreated with the same name, after we gather > information about all the tables and we acquire the lock. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-24796) [HS2] Enhance DriverTxnHandler.isValidTxnListState logic to include tableId comparison
[ https://issues.apache.org/jira/browse/HIVE-24796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304277#comment-17304277 ] Kishen Das commented on HIVE-24796: --- This would take care of the above issue -> https://issues.apache.org/jira/browse/HIVE-24662 . > [HS2] Enhance DriverTxnHandler.isValidTxnListState logic to include tableId > comparison > -- > > Key: HIVE-24796 > URL: https://issues.apache.org/jira/browse/HIVE-24796 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > In HS2, after query compilation phase, we acquire lock in DriverTxnHandler. > isValidTxnListState and later ensure there are no conflicting transactions by > using driverContext.getTxnManager().getLatestTxnIdInConflict(); . This > doesn't work well, if there are external entities that drop and recreate the > table with the same name. So, we should also make sure the tableId itself is > not changed, after lock has been acquired. This Jira is to enhance the > DriverTxnHandler.isValidTxnListState logic to include tableId comparison. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (HIVE-23820) [HS2] Send tableId in request for get_table_request API
[ https://issues.apache.org/jira/browse/HIVE-23820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299867#comment-17299867 ] Kishen Das edited comment on HIVE-23820 at 3/12/21, 12:11 AM: -- [~ashish-kumar-sharma] Sure, you can work on this. Btw how are you planning to pass tableId in get_table_req API ? I was thinking of enhancing getValidWriteIdList to return tableId as well and sending that back in the get_table_req API. We can also cache tableId at the Hive session level when we make get_table_req for the first time in compilation phase and and send it back in get_table_req API in subsequent calls within the same session. was (Author: kishendas): [~ashish-kumar-sharma] Sure, you can work on this. Btw how are you planning to pass tableId in get_table_req API ? I was thinking of enhancing getValidWriteIdList to return tableId as well and sending that back in the get_table_req API. > [HS2] Send tableId in request for get_table_request API > --- > > Key: HIVE-23820 > URL: https://issues.apache.org/jira/browse/HIVE-23820 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Ashish Sharma >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-23820) [HS2] Send tableId in request for get_table_request API
[ https://issues.apache.org/jira/browse/HIVE-23820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-23820: - Assignee: Ashish Sharma (was: Kishen Das) > [HS2] Send tableId in request for get_table_request API > --- > > Key: HIVE-23820 > URL: https://issues.apache.org/jira/browse/HIVE-23820 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Ashish Sharma >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-23820) [HS2] Send tableId in request for get_table_request API
[ https://issues.apache.org/jira/browse/HIVE-23820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299867#comment-17299867 ] Kishen Das commented on HIVE-23820: --- [~ashish-kumar-sharma] Sure, you can work on this. Btw how are you planning to pass tableId in get_table_req API ? I was thinking of enhancing getValidWriteIdList to return tableId as well and sending that back in the get_table_req API. > [HS2] Send tableId in request for get_table_request API > --- > > Key: HIVE-23820 > URL: https://issues.apache.org/jira/browse/HIVE-23820 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24828) [HMS] Provide new HMS API to return latest committed compaction record for a given table
[ https://issues.apache.org/jira/browse/HIVE-24828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24828: -- Description: We need a new HMS API to return the latest committed compaction record for a given table. This can be used by a remote cache to decide whether a given table's file metadata has been compacted or not, in order to decide whether file metadata has to be refreshed from the file system before serving or it can serve the current data from the cache. (was: We need a new HMS API to return the latest committed compaction record for a given table. This can be used by a remote cache to decide whether a given table's file metadata has been compacted or not, in order to decide whether that information has to be refreshed from the file system before serving or it can serve the current data from the cache. ) > [HMS] Provide new HMS API to return latest committed compaction record for a > given table > > > Key: HIVE-24828 > URL: https://issues.apache.org/jira/browse/HIVE-24828 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > We need a new HMS API to return the latest committed compaction record for a > given table. This can be used by a remote cache to decide whether a given > table's file metadata has been compacted or not, in order to decide whether > file metadata has to be refreshed from the file system before serving or it > can serve the current data from the cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-24828) [HMS] Provide new HMS API to return latest committed compaction record for a given table
[ https://issues.apache.org/jira/browse/HIVE-24828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-24828: - Assignee: Kishen Das > [HMS] Provide new HMS API to return latest committed compaction record for a > given table > > > Key: HIVE-24828 > URL: https://issues.apache.org/jira/browse/HIVE-24828 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > We need a new HMS API to return the latest committed compaction record for a > given table. This can be used by a remote cache to decide whether a given > table's file metadata has been compacted or not, in order to decide whether > that information has to be refreshed from the file system before serving or > it can serve the current data from the cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HIVE-24743) [HS2] Send tableId to get_partitions_by_names_req HMS API from HS2
[ https://issues.apache.org/jira/browse/HIVE-24743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das resolved HIVE-24743. --- Resolution: Fixed > [HS2] Send tableId to get_partitions_by_names_req HMS API from HS2 > -- > > Key: HIVE-24743 > URL: https://issues.apache.org/jira/browse/HIVE-24743 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > Labels: pull-request-available > Time Spent: 2.5h > Remaining Estimate: 0h > > As part of ( HIVE-23821: Send tableId in request for all the new HMS > get_partition APIs ) we added logic to send tableId in the request for > several get_partition APIs, but looks like it was missed out for > getPartitionsByNames. TableId and validWriteIdList are used to maintain > consistency, when HMS API response is being served from a remote cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-24796) [HS2] Enhance DriverTxnHandler.isValidTxnListState logic to include tableId comparison
[ https://issues.apache.org/jira/browse/HIVE-24796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-24796: - Assignee: Kishen Das > [HS2] Enhance DriverTxnHandler.isValidTxnListState logic to include tableId > comparison > -- > > Key: HIVE-24796 > URL: https://issues.apache.org/jira/browse/HIVE-24796 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > In HS2, after query compilation phase, we acquire lock in DriverTxnHandler. > isValidTxnListState and later ensure there are no conflicting transactions by > using driverContext.getTxnManager().getLatestTxnIdInConflict(); . This > doesn't work well, if there are external entities that drop and recreate the > table with the same name. So, we should also make sure the tableId itself is > not changed, after lock has been acquired. This Jira is to enhance the > DriverTxnHandler.isValidTxnListState logic to include tableId comparison. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-24795) [HS2] Cache tableId in SessionState
[ https://issues.apache.org/jira/browse/HIVE-24795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-24795: - Assignee: Kishen Das > [HS2] Cache tableId in SessionState > > > Key: HIVE-24795 > URL: https://issues.apache.org/jira/browse/HIVE-24795 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Please go through https://issues.apache.org/jira/browse/HIVE-24794 to > understand why this is required. Its basically to handle a corner case, in > which a table gets dropped and recreated with the same name, after we gather > information about all the tables and we acquire the lock. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24794) [HMS] Populate tableId in the response of get_valid_write_ids API
[ https://issues.apache.org/jira/browse/HIVE-24794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24794: -- Summary: [HMS] Populate tableId in the response of get_valid_write_ids API (was: Populate tableId in the response of get_valid_write_ids API) > [HMS] Populate tableId in the response of get_valid_write_ids API > - > > Key: HIVE-24794 > URL: https://issues.apache.org/jira/browse/HIVE-24794 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Priority: Major > > In HS2, after query compilation phase, we acquire lock in DriverTxnHandler. > isValidTxnListState and later ensure there are no conflicting transactions by > using driverContext.getTxnManager().getLatestTxnIdInConflict(); . This > doesn't work well, if there are external entities that drop and recreate the > table with the same name. So, we should also make sure the tableId itself is > not changed, after lock has been acquired. This Jira is to enhance > getValidWriteIdList to return tableId as well. Idea is to cache the tableId > in SessionState and later compare it with what getValidWriteIdList returns. > If the table was dropped and recreated, the tableId will not match and we > have to recompile the query. Caching the tableId in SessionState will be done > as part of a separate Jira. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24795) [HS2] Cache tableId in SessionState
[ https://issues.apache.org/jira/browse/HIVE-24795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24795: -- Summary: [HS2] Cache tableId in SessionState (was: Cache tableId in SessionState ) > [HS2] Cache tableId in SessionState > > > Key: HIVE-24795 > URL: https://issues.apache.org/jira/browse/HIVE-24795 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Priority: Major > > Please go through https://issues.apache.org/jira/browse/HIVE-24794 to > understand why this is required. Its basically to handle a corner case, in > which a table gets dropped and recreated with the same name, after we gather > information about all the tables and we acquire the lock. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-24794) [HMS] Populate tableId in the response of get_valid_write_ids API
[ https://issues.apache.org/jira/browse/HIVE-24794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-24794: - Assignee: Kishen Das > [HMS] Populate tableId in the response of get_valid_write_ids API > - > > Key: HIVE-24794 > URL: https://issues.apache.org/jira/browse/HIVE-24794 > Project: Hive > Issue Type: Sub-task > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > In HS2, after query compilation phase, we acquire lock in DriverTxnHandler. > isValidTxnListState and later ensure there are no conflicting transactions by > using driverContext.getTxnManager().getLatestTxnIdInConflict(); . This > doesn't work well, if there are external entities that drop and recreate the > table with the same name. So, we should also make sure the tableId itself is > not changed, after lock has been acquired. This Jira is to enhance > getValidWriteIdList to return tableId as well. Idea is to cache the tableId > in SessionState and later compare it with what getValidWriteIdList returns. > If the table was dropped and recreated, the tableId will not match and we > have to recompile the query. Caching the tableId in SessionState will be done > as part of a separate Jira. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-24743) [HS2] Send tableId to get_partitions_by_names_req HMS API from HS2
[ https://issues.apache.org/jira/browse/HIVE-24743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-24743: - Assignee: Kishen Das > [HS2] Send tableId to get_partitions_by_names_req HMS API from HS2 > -- > > Key: HIVE-24743 > URL: https://issues.apache.org/jira/browse/HIVE-24743 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > As part of ( HIVE-23821: Send tableId in request for all the new HMS > get_partition APIs ) we added logic to send tableId in the request for > several get_partition APIs, but looks like it was missed out for > getPartitionsByNames. TableId and validWriteIdList are used to maintain > consistency, when HMS API response is being served from a remote cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HIVE-24743) [HS2] Send tableId to get_partitions_by_names_req HMS API from HS2
[ https://issues.apache.org/jira/browse/HIVE-24743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HIVE-24743 started by Kishen Das. - > [HS2] Send tableId to get_partitions_by_names_req HMS API from HS2 > -- > > Key: HIVE-24743 > URL: https://issues.apache.org/jira/browse/HIVE-24743 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > As part of ( HIVE-23821: Send tableId in request for all the new HMS > get_partition APIs ) we added logic to send tableId in the request for > several get_partition APIs, but looks like it was missed out for > getPartitionsByNames. TableId and validWriteIdList are used to maintain > consistency, when HMS API response is being served from a remote cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HIVE-24513) Advance write Id during AlterTableDropConstraint DDL
[ https://issues.apache.org/jira/browse/HIVE-24513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das resolved HIVE-24513. --- Resolution: Fixed > Advance write Id during AlterTableDropConstraint DDL > > > Key: HIVE-24513 > URL: https://issues.apache.org/jira/browse/HIVE-24513 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > For AlterTableDropConstraint related DDL tasks, although we might be > advancing the write ID, looks like it's not updated correctly during the > Analyzer phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24618) Hive JDBC should do timestamp conversions in UTC
[ https://issues.apache.org/jira/browse/HIVE-24618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24618: -- Summary: Hive JDBC should do timestamp conversions in UTC (was: Hive JDBC handler should do timestamp conversions in UTC) > Hive JDBC should do timestamp conversions in UTC > > > Key: HIVE-24618 > URL: https://issues.apache.org/jira/browse/HIVE-24618 > Project: Hive > Issue Type: Bug > Components: JDBC >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( > https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent > w.r.t timestamp field irrespective of the current time zone. For example: for > time zones like America/Los_Angeles that alternate between PST and PDT, time > can be shown based on effective current time zone, which is set in the > current SQL session. Hive JDBC handler should follow suit and use > LocalDateTime ( A date-time without a time-zone ), when doing the conversion, > so that original timestamp returned by Hive is preserved. > > This issue is also more pronounced because of this bug in Java -> > [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24618) Hive JDBC handler should do timestamp conversions in UTC
[ https://issues.apache.org/jira/browse/HIVE-24618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24618: -- Description: Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent w.r.t timestamp field irrespective of the current time zone. For example: for time zones like America/Los_Angeles that alternate between PST and PDT, time can be shown based on effective current time zone, which is set in the current SQL session. Hive JDBC handler should follow suit and use LocalDateTime ( A date-time without a time-zone ), when doing the conversion, so that original timestamp returned by Hive is preserved. This issue is also more pronounced because of this bug in Java -> [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . was: Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent w.r.t timestamp field irrespective of the current time zone. For example: for time zones like America/Los_Angeles that alternate between PST and PDT, time can be shown based on effective current time zone, which is set in the current SQL session. Hive JDBC handler should follow suit and use LocalDateTime ( A date-time without a time-zone ), when doing the conversion. This issue is also more pronounced because of this bug in Java -> [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . > Hive JDBC handler should do timestamp conversions in UTC > > > Key: HIVE-24618 > URL: https://issues.apache.org/jira/browse/HIVE-24618 > Project: Hive > Issue Type: Bug > Components: JDBC >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( > https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent > w.r.t timestamp field irrespective of the current time zone. For example: for > time zones like America/Los_Angeles that alternate between PST and PDT, time > can be shown based on effective current time zone, which is set in the > current SQL session. Hive JDBC handler should follow suit and use > LocalDateTime ( A date-time without a time-zone ), when doing the conversion, > so that original timestamp returned by Hive is preserved. > > This issue is also more pronounced because of this bug in Java -> > [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24618) Hive JDBC handler should do timestamp conversions in UTC
[ https://issues.apache.org/jira/browse/HIVE-24618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24618: -- Summary: Hive JDBC handler should do timestamp conversions in UTC (was: Hive JDBC should use java.time.LocalDateTime instead of timestamp) > Hive JDBC handler should do timestamp conversions in UTC > > > Key: HIVE-24618 > URL: https://issues.apache.org/jira/browse/HIVE-24618 > Project: Hive > Issue Type: Bug > Components: JDBC >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( > https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent > w.r.t timestamp field irrespective of the current time zone. For example: for > time zones like America/Los_Angeles that alternate between PST and PDT, time > can be shown based on effective current time zone, which is set in the > current SQL session. Hive JDBC handler should follow suit and use > LocalDateTime ( A date-time without a time-zone ), when doing the conversion. > > > This issue is also more pronounced because of this bug in Java -> > [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24618) Hive JDBC should use java.time.LocalDateTime instead of timestamp
[ https://issues.apache.org/jira/browse/HIVE-24618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24618: -- Summary: Hive JDBC should use java.time.LocalDateTime instead of timestamp (was: Hive JDBC should use java.time.LocalDateTime ) > Hive JDBC should use java.time.LocalDateTime instead of timestamp > - > > Key: HIVE-24618 > URL: https://issues.apache.org/jira/browse/HIVE-24618 > Project: Hive > Issue Type: Bug > Components: JDBC >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( > https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent > w.r.t timestamp field irrespective of the current time zone. For example: for > time zones like America/Los_Angeles that alternate between PST and PDT, time > can be shown based on effective current time zone, which is set in the > current SQL session. Hive JDBC handler should follow suit and use > LocalDateTime ( A date-time without a time-zone ), when doing the conversion. > > > This issue is also more pronounced because of this bug in Java -> > [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24618) Hive JDBC should use java.time.LocalDateTime
[ https://issues.apache.org/jira/browse/HIVE-24618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24618: -- Summary: Hive JDBC should use java.time.LocalDateTime (was: Hive JDBC should use timestamp in UTC) > Hive JDBC should use java.time.LocalDateTime > - > > Key: HIVE-24618 > URL: https://issues.apache.org/jira/browse/HIVE-24618 > Project: Hive > Issue Type: Bug > Components: JDBC >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( > https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent > w.r.t timestamp field irrespective of the current time zone. For example: for > time zones like America/Los_Angeles that alternate between PST and PDT, time > can be shown based on effective current time zone, which is set in the > current SQL session. Hive JDBC handler should follow suit and use > LocalDateTime ( A date-time without a time-zone ), when doing the conversion. > > > This issue is also more pronounced because of this bug in Java -> > [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24618) Hive JDBC should use timestamp in UTC
[ https://issues.apache.org/jira/browse/HIVE-24618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24618: -- Description: Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent w.r.t timestamp field irrespective of the current time zone. For example: for time zones like America/Los_Angeles that alternate between PST and PDT, time can be shown based on effective current time zone, which is set in the current SQL session. Hive JDBC handler should follow suit and use LocalDateTime ( A date-time without a time-zone ), when doing the conversion. This issue is also more pronounced because of this bug in Java -> [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . was: Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent w.r.t timestamp field irrespective of the current time zone. For example: for time zones like America/Los_Angeles that alternate between PST and PDT, time can be shown based on effective current time zone, which is set in the current SQL session. Hive JDBC handler should follow suit and use LocalDateTime ( A date-time without a time-zone ), when doing the conversion. Also, it might be helpful if the user can set the user timezone in Beeline session, lets say "user.timezone”, which should be honored while showing the beeline output of a particular timestamp field. This issue is also more pronounced because of this bug in Java -> [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . > Hive JDBC should use timestamp in UTC > - > > Key: HIVE-24618 > URL: https://issues.apache.org/jira/browse/HIVE-24618 > Project: Hive > Issue Type: Bug > Components: JDBC >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( > https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent > w.r.t timestamp field irrespective of the current time zone. For example: for > time zones like America/Los_Angeles that alternate between PST and PDT, time > can be shown based on effective current time zone, which is set in the > current SQL session. Hive JDBC handler should follow suit and use > LocalDateTime ( A date-time without a time-zone ), when doing the conversion. > > > This issue is also more pronounced because of this bug in Java -> > [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HIVE-24618) Hive JDBC should use timestamp in UTC
[ https://issues.apache.org/jira/browse/HIVE-24618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HIVE-24618 started by Kishen Das. - > Hive JDBC should use timestamp in UTC > - > > Key: HIVE-24618 > URL: https://issues.apache.org/jira/browse/HIVE-24618 > Project: Hive > Issue Type: Bug > Components: JDBC >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( > https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent > w.r.t timestamp field irrespective of the current time zone. For example: for > time zones like America/Los_Angeles that alternate between PST and PDT, time > can be shown based on effective current time zone, which is set in the > current SQL session. Hive JDBC handler should follow suit and use > LocalDateTime ( A date-time without a time-zone ), when doing the conversion. > Also, it might be helpful if the user can set the user timezone in Beeline > session, lets say "user.timezone”, which should be honored while showing the > beeline output of a particular timestamp field. > > This issue is also more pronounced because of this bug in Java -> > [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-24618) Hive JDBC should use timestamp in UTC
[ https://issues.apache.org/jira/browse/HIVE-24618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-24618: - Assignee: Kishen Das > Hive JDBC should use timestamp in UTC > - > > Key: HIVE-24618 > URL: https://issues.apache.org/jira/browse/HIVE-24618 > Project: Hive > Issue Type: Bug > Components: JDBC >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( > https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent > w.r.t timestamp field irrespective of the current time zone. For example: for > time zones like America/Los_Angeles that alternate between PST and PDT, time > can be shown based on effective current time zone, which is set in the > current SQL session. Hive JDBC handler should follow suit and use > LocalDateTime ( A date-time without a time-zone ), when doing the conversion. > Also, it might be helpful if the user can set the user timezone in Beeline > session, lets say "user.timezone”, which should be honored while showing the > beeline output of a particular timestamp field. > > This issue is also more pronounced because of this bug in Java -> > [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24618) Hive JDBC should use timestamp in UTC
[ https://issues.apache.org/jira/browse/HIVE-24618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24618: -- Description: Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent w.r.t timestamp field irrespective of the current time zone. For example: for time zones like America/Los_Angeles that alternate between PST and PDT, time can be shown based on effective current time zone, which is set in the current SQL session. Hive JDBC handler should follow suit and use LocalDateTime ( A date-time without a time-zone ), when doing the conversion. Also, it might be helpful if the user can set the user timezone in Beeline session, lets say "user.timezone”, which should be honored while showing the beeline output of a particular timestamp field. This issue is also more pronounced because of this bug in Java -> [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . was: Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent w.r.t timestamp field irrespective of the current time zone. For example: for time zones like America/Los_Angeles that alternate between PST and PDT, time can be shown based on effective current time zone, which is set in the current SQL session. Hive Beeline should follow suit and use LocalDateTime ( A date-time without a time-zone ), when doing the conversion. Also, it might be helpful if the user can set the user timezone in Beeline session, lets say "user.timezone”, which should be honored while showing the beeline output of a particular timestamp field. This issue is also more pronounced because of this bug in Java -> [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . > Hive JDBC should use timestamp in UTC > - > > Key: HIVE-24618 > URL: https://issues.apache.org/jira/browse/HIVE-24618 > Project: Hive > Issue Type: Bug > Components: JDBC >Reporter: Kishen Das >Priority: Major > > Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( > https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent > w.r.t timestamp field irrespective of the current time zone. For example: for > time zones like America/Los_Angeles that alternate between PST and PDT, time > can be shown based on effective current time zone, which is set in the > current SQL session. Hive JDBC handler should follow suit and use > LocalDateTime ( A date-time without a time-zone ), when doing the conversion. > Also, it might be helpful if the user can set the user timezone in Beeline > session, lets say "user.timezone”, which should be honored while showing the > beeline output of a particular timestamp field. > > This issue is also more pronounced because of this bug in Java -> > [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24618) Hive Beeline should use timestamp in UTC
[ https://issues.apache.org/jira/browse/HIVE-24618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24618: -- Component/s: (was: Beeline) JDBC > Hive Beeline should use timestamp in UTC > > > Key: HIVE-24618 > URL: https://issues.apache.org/jira/browse/HIVE-24618 > Project: Hive > Issue Type: Bug > Components: JDBC >Reporter: Kishen Das >Priority: Major > > Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( > https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent > w.r.t timestamp field irrespective of the current time zone. For example: for > time zones like America/Los_Angeles that alternate between PST and PDT, time > can be shown based on effective current time zone, which is set in the > current SQL session. Hive Beeline should follow suit and use LocalDateTime ( > A date-time without a time-zone ), when doing the conversion. Also, it might > be helpful if the user can set the user timezone in Beeline session, lets say > "user.timezone”, which should be honored while showing the beeline output of > a particular timestamp field. > > This issue is also more pronounced because of this bug in Java -> > [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24618) Hive JDBC should use timestamp in UTC
[ https://issues.apache.org/jira/browse/HIVE-24618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24618: -- Summary: Hive JDBC should use timestamp in UTC (was: Hive Beeline should use timestamp in UTC) > Hive JDBC should use timestamp in UTC > - > > Key: HIVE-24618 > URL: https://issues.apache.org/jira/browse/HIVE-24618 > Project: Hive > Issue Type: Bug > Components: JDBC >Reporter: Kishen Das >Priority: Major > > Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( > https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent > w.r.t timestamp field irrespective of the current time zone. For example: for > time zones like America/Los_Angeles that alternate between PST and PDT, time > can be shown based on effective current time zone, which is set in the > current SQL session. Hive Beeline should follow suit and use LocalDateTime ( > A date-time without a time-zone ), when doing the conversion. Also, it might > be helpful if the user can set the user timezone in Beeline session, lets say > "user.timezone”, which should be honored while showing the beeline output of > a particular timestamp field. > > This issue is also more pronounced because of this bug in Java -> > [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24618) Hive Beeline should use timestamp in UTC
[ https://issues.apache.org/jira/browse/HIVE-24618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24618: -- Description: Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent w.r.t timestamp field irrespective of the current time zone. For example: for time zones like America/Los_Angeles that alternate between PST and PDT, time can be shown based on effective current time zone, which is set in the current SQL session. Hive Beeline should follow suit and use LocalDateTime ( A date-time without a time-zone ), when doing the conversion. Also, it might be helpful if the user can set the user timezone in Beeline session, lets say "user.timezone”, which should be honored while showing the beeline output of a particular timestamp field. This issue is also more pronounced because of this bug in Java -> [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . was: Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( https://issues.apache.org/jira/browse/HIVE-12192, in order to be consistent w.r.t timestamp field irrespective of the current time zone. For example: for time zones like America/Los_Angeles that alternate between PST and PDT, time can be shown based on effective current time zone, which is set in the current SQL session. Hive Beeline should follow suit and use LocalDateTime ( A date-time without a time-zone ), when doing the conversion. Also, it might be helpful if the user can set the user timezone in Beeline session, lets say "user.timezone”, which should be honored while showing the beeline output of a particular timestamp field. This issue is also more pronounced because of this bug in Java -> [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . > Hive Beeline should use timestamp in UTC > > > Key: HIVE-24618 > URL: https://issues.apache.org/jira/browse/HIVE-24618 > Project: Hive > Issue Type: Bug > Components: Beeline >Reporter: Kishen Das >Priority: Major > > Hive moved away from java.sql.Timestamp to java.time.LocalDateTime ( > https://issues.apache.org/jira/browse/HIVE-12192 ), in order to be consistent > w.r.t timestamp field irrespective of the current time zone. For example: for > time zones like America/Los_Angeles that alternate between PST and PDT, time > can be shown based on effective current time zone, which is set in the > current SQL session. Hive Beeline should follow suit and use LocalDateTime ( > A date-time without a time-zone ), when doing the conversion. Also, it might > be helpful if the user can set the user timezone in Beeline session, lets say > "user.timezone”, which should be honored while showing the beeline output of > a particular timestamp field. > > This issue is also more pronounced because of this bug in Java -> > [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8258586] . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (HIVE-24513) Advance write Id during AlterTableDropConstraint DDL
[ https://issues.apache.org/jira/browse/HIVE-24513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24513: -- Comment: was deleted (was: https://github.com/apache/hive/pull/1788) > Advance write Id during AlterTableDropConstraint DDL > > > Key: HIVE-24513 > URL: https://issues.apache.org/jira/browse/HIVE-24513 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > For AlterTableDropConstraint related DDL tasks, although we might be > advancing the write ID, looks like it's not updated correctly during the > Analyzer phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-24513) Advance write Id during AlterTableDropConstraint DDL
[ https://issues.apache.org/jira/browse/HIVE-24513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17250220#comment-17250220 ] Kishen Das commented on HIVE-24513: --- https://github.com/apache/hive/pull/1788 > Advance write Id during AlterTableDropConstraint DDL > > > Key: HIVE-24513 > URL: https://issues.apache.org/jira/browse/HIVE-24513 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > For AlterTableDropConstraint related DDL tasks, although we might be > advancing the write ID, looks like it's not updated correctly during the > Analyzer phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HIVE-24482) Advance write Id during AlterTableAddConstraint DDL
[ https://issues.apache.org/jira/browse/HIVE-24482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das resolved HIVE-24482. --- Resolution: Fixed > Advance write Id during AlterTableAddConstraint DDL > --- > > Key: HIVE-24482 > URL: https://issues.apache.org/jira/browse/HIVE-24482 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > For AlterTableAddConstraint related DDL tasks, although we might be advancing > the write ID, looks like it's not updated correctly during the Analyzer > phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HIVE-24513) Advance write Id during AlterTableDropConstraint DDL
[ https://issues.apache.org/jira/browse/HIVE-24513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HIVE-24513 started by Kishen Das. - > Advance write Id during AlterTableDropConstraint DDL > > > Key: HIVE-24513 > URL: https://issues.apache.org/jira/browse/HIVE-24513 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > For AlterTableDropConstraint related DDL tasks, although we might be > advancing the write ID, looks like it's not updated correctly during the > Analyzer phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HIVE-24520) Fix stackoverflow error in HiveMetaStore::get_partitions_by_names
[
https://issues.apache.org/jira/browse/HIVE-24520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HIVE-24520 started by Kishen Das.
-
> Fix stackoverflow error in HiveMetaStore::get_partitions_by_names
> -
>
> Key: HIVE-24520
> URL: https://issues.apache.org/jira/browse/HIVE-24520
> Project: Hive
> Issue Type: Improvement
>Reporter: Rajesh Balamohan
>Assignee: Kishen Das
>Priority: Major
>
> Need to fix the recursive call of the same method.
>
> (May have been introduced as a part of
> https://issues.apache.org/jira/browse/HIVE-22017)
>
> {code:java}
> @Override
> @Deprecated
> public List get_partitions_by_names(final String dbName, final
> String tblName,
>final List
> partNames)
> throws TException {
> return get_partitions_by_names(dbName, tblName, partNames);
> }
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (HIVE-24520) Fix stackoverflow error in HiveMetaStore::get_partitions_by_names
[
https://issues.apache.org/jira/browse/HIVE-24520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishen Das reassigned HIVE-24520:
-
Assignee: Kishen Das
> Fix stackoverflow error in HiveMetaStore::get_partitions_by_names
> -
>
> Key: HIVE-24520
> URL: https://issues.apache.org/jira/browse/HIVE-24520
> Project: Hive
> Issue Type: Improvement
>Reporter: Rajesh Balamohan
>Assignee: Kishen Das
>Priority: Major
>
> Need to fix the recursive call of the same method.
>
> (May have been introduced as a part of
> https://issues.apache.org/jira/browse/HIVE-22017)
>
> {code:java}
> @Override
> @Deprecated
> public List get_partitions_by_names(final String dbName, final
> String tblName,
>final List
> partNames)
> throws TException {
> return get_partitions_by_names(dbName, tblName, partNames);
> }
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (HIVE-24513) Advance write Id during AlterTableDropConstraint DDL
[ https://issues.apache.org/jira/browse/HIVE-24513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-24513: - > Advance write Id during AlterTableDropConstraint DDL > > > Key: HIVE-24513 > URL: https://issues.apache.org/jira/browse/HIVE-24513 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > For AlterTableDropConstraint related DDL tasks, although we might be > advancing the write ID, looks like it's not updated correctly during the > Analyzer phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-24482) Advance write Id during AlterTableAddConstraint DDL
[ https://issues.apache.org/jira/browse/HIVE-24482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17246213#comment-17246213 ] Kishen Das commented on HIVE-24482: --- https://github.com/apache/hive/pull/1737 > Advance write Id during AlterTableAddConstraint DDL > --- > > Key: HIVE-24482 > URL: https://issues.apache.org/jira/browse/HIVE-24482 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > For AlterTableAddConstraint related DDL tasks, although we might be advancing > the write ID, looks like it's not updated correctly during the Analyzer > phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (HIVE-24482) Advance write Id during AlterTableAddConstraint DDL
[ https://issues.apache.org/jira/browse/HIVE-24482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243343#comment-17243343 ] Kishen Das edited comment on HIVE-24482 at 12/3/20, 4:51 PM: - [~dkuzmenko] That's the idea, once we implement all the subtasks. Rather than going directly to DB, CachedStore is supposed to refresh the latest data from DB, before serving. [~ashish-kumar-sharma] is driving the CachedStore changes. was (Author: kishendas): [~dkuzmenko] That's the idea, once we implement all the subtasks. [~ashish-kumar-sharma] is driving the CachedStore changes. > Advance write Id during AlterTableAddConstraint DDL > --- > > Key: HIVE-24482 > URL: https://issues.apache.org/jira/browse/HIVE-24482 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > For AlterTableAddConstraint related DDL tasks, although we might be advancing > the write ID, looks like it's not updated correctly during the Analyzer > phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-24482) Advance write Id during AlterTableAddConstraint DDL
[ https://issues.apache.org/jira/browse/HIVE-24482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243343#comment-17243343 ] Kishen Das commented on HIVE-24482: --- [~dkuzmenko] That's the idea, once we implement all the subtasks. [~ashish-kumar-sharma] is driving the CachedStore changes. > Advance write Id during AlterTableAddConstraint DDL > --- > > Key: HIVE-24482 > URL: https://issues.apache.org/jira/browse/HIVE-24482 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > For AlterTableAddConstraint related DDL tasks, although we might be advancing > the write ID, looks like it's not updated correctly during the Analyzer > phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-24482) Advance write Id during AlterTableAddConstraint DDL
[ https://issues.apache.org/jira/browse/HIVE-24482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243303#comment-17243303 ] Kishen Das commented on HIVE-24482: --- [~dkuzmenko] Please go through -> [https://cwiki.apache.org/confluence/display/Hive/Synchronized+Metastore+Cache] . > Advance write Id during AlterTableAddConstraint DDL > --- > > Key: HIVE-24482 > URL: https://issues.apache.org/jira/browse/HIVE-24482 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > For AlterTableAddConstraint related DDL tasks, although we might be advancing > the write ID, looks like it's not updated correctly during the Analyzer > phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-24482) Advance write Id during AlterTableAddConstraint DDL
[ https://issues.apache.org/jira/browse/HIVE-24482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-24482: - Assignee: Kishen Das > Advance write Id during AlterTableAddConstraint DDL > --- > > Key: HIVE-24482 > URL: https://issues.apache.org/jira/browse/HIVE-24482 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > For AlterTableAddConstraint related DDL tasks, although we might be advancing > the write ID, looks like it's not updated correctly during the Analyzer > phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HIVE-24482) Advance write Id during AlterTableAddConstraint DDL
[ https://issues.apache.org/jira/browse/HIVE-24482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HIVE-24482 started by Kishen Das. - > Advance write Id during AlterTableAddConstraint DDL > --- > > Key: HIVE-24482 > URL: https://issues.apache.org/jira/browse/HIVE-24482 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > For AlterTableAddConstraint related DDL tasks, although we might be advancing > the write ID, looks like it's not updated correctly during the Analyzer > phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24275) Configurations to delay the deletion of obsolete files by the Cleaner
[ https://issues.apache.org/jira/browse/HIVE-24275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24275: -- Description: Whenever compaction happens, the cleaner immediately deletes older obsolete files. In certain cases it would be beneficial to retain these for certain period. For example : if you are serving the file metadata from cache and don't want to invalidate the cache during compaction because of performance reasons. For this purpose we should introduce a configuration hive.compactor.delayed.cleanup.enabled, which if enabled will delay the cleaning up obsolete files. There should be a separate configuration CLEANER_RETENTION_TIME to specify the duration till which we should retain these older obsolete files. It might be beneficial to have one more configuration to decide whether to retain files involved in an aborted transaction hive.compactor.aborted.txn.delayed.cleanup.enabled . was: Whenever compaction happens, the cleaner immediately deletes older obsolete files. In certain cases it would be beneficial to retain these for certain period. For example : if you are serving the file metadata from cache and don't want to invalidate the cache during compaction because of performance reasons. For this purpose we should introduce a configuration hive.compactor.delayed.cleanup.enabled, which if enabled will delay the cleaning up obsolete files. There should be a separate configuration CLEANER_RETENTION_TIME to specific the duration till which we should retain these older obsolete files. It might be beneficial to have one more configuration to decide whether to retain files involved in an aborted transaction hive.compactor.aborted.txn.delayed.cleanup.enabled . > Configurations to delay the deletion of obsolete files by the Cleaner > - > > Key: HIVE-24275 > URL: https://issues.apache.org/jira/browse/HIVE-24275 > Project: Hive > Issue Type: New Feature >Reporter: Kishen Das >Priority: Major > > Whenever compaction happens, the cleaner immediately deletes older obsolete > files. In certain cases it would be beneficial to retain these for certain > period. For example : if you are serving the file metadata from cache and > don't want to invalidate the cache during compaction because of performance > reasons. > For this purpose we should introduce a configuration > hive.compactor.delayed.cleanup.enabled, which if enabled will delay the > cleaning up obsolete files. There should be a separate configuration > CLEANER_RETENTION_TIME to specify the duration till which we should retain > these older obsolete files. > It might be beneficial to have one more configuration to decide whether to > retain files involved in an aborted transaction > hive.compactor.aborted.txn.delayed.cleanup.enabled . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24275) Configurations to delay the deletion of obsolete files by the Cleaner
[ https://issues.apache.org/jira/browse/HIVE-24275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24275: -- Summary: Configurations to delay the deletion of obsolete files by the Cleaner (was: Introduce a configuration to delay the deletion of obsolete files by the Cleaner) > Configurations to delay the deletion of obsolete files by the Cleaner > - > > Key: HIVE-24275 > URL: https://issues.apache.org/jira/browse/HIVE-24275 > Project: Hive > Issue Type: New Feature >Reporter: Kishen Das >Priority: Major > > Whenever compaction happens, the cleaner immediately deletes older obsolete > files. In certain cases it would be beneficial to retain these for certain > period. For example : if you are serving the file metadata from cache and > don't want to invalidate the cache during compaction because of performance > reasons. > For this purpose we should introduce a configuration > hive.compactor.delayed.cleanup.enabled, which if enabled will delay the > cleaning up obsolete files. There should be a separate configuration > CLEANER_RETENTION_TIME to specific the duration till which we should retain > these older obsolete files. > It might be beneficial to have one more configuration to decide whether to > retain files involved in an aborted transaction > hive.compactor.aborted.txn.delayed.cleanup.enabled . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-24182) Ranger authorization issue with permanent UDFs
[ https://issues.apache.org/jira/browse/HIVE-24182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17198698#comment-17198698 ] Kishen Das commented on HIVE-24182: --- Pull request -> [https://github.com/apache/hive/pull/1510] > Ranger authorization issue with permanent UDFs > -- > > Key: HIVE-24182 > URL: https://issues.apache.org/jira/browse/HIVE-24182 > Project: Hive > Issue Type: Bug > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > We are creating the permanent function names as WINDOW_FUNC_PREFIX + > DB.PERMANENT_FUNCTION_NAME which was introduced by > https://issues.apache.org/jira/browse/HIVE-12719 . > When we populate read entities for permanent functions, we add ReadEntity > which has DB in the format WINDOW_FUNC_PREFIX + DB. Since Ranger policies are > only configured for a given database whose name is just DB and not > WINDOW_FUNC_PREFIX + DB, we should modify the DB name to remove the prefix > WINDOW_FUNC_PREFIX, when we are creating the read entity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-24182) Ranger authorization issue with permanent UDFs
[ https://issues.apache.org/jira/browse/HIVE-24182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-24182: -- Description: We are creating the permanent function names as WINDOW_FUNC_PREFIX + DB.PERMANENT_FUNCTION_NAME which was introduced by https://issues.apache.org/jira/browse/HIVE-12719 . When we populate read entities for permanent functions, we add ReadEntity which has DB in the format WINDOW_FUNC_PREFIX + DB. Since Ranger policies are only configured for a given database whose name is just DB and not WINDOW_FUNC_PREFIX + DB, we should modify the DB name to remove the prefix WINDOW_FUNC_PREFIX, when we are creating the read entity. was: We are creating the permanent function names as WINDOW_FUNC_PREFIX + DB.PERMANENT_FUNCTION_NAME which was introduced by https://issues.apache.org/jira/browse/HIVE-12719 . When we populate read entities for permanent functions, we add ReadEntity which has DB in the format WINDOW_FUNC_PREFIX + DB. Since Ranger policies are only configured for a given database whose name is just DB and not WINDOW_FUNC_PREFIX + DB. We should fix the DB name, when we are creating the read entity. > Ranger authorization issue with permanent UDFs > -- > > Key: HIVE-24182 > URL: https://issues.apache.org/jira/browse/HIVE-24182 > Project: Hive > Issue Type: Bug > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > We are creating the permanent function names as WINDOW_FUNC_PREFIX + > DB.PERMANENT_FUNCTION_NAME which was introduced by > https://issues.apache.org/jira/browse/HIVE-12719 . > When we populate read entities for permanent functions, we add ReadEntity > which has DB in the format WINDOW_FUNC_PREFIX + DB. Since Ranger policies are > only configured for a given database whose name is just DB and not > WINDOW_FUNC_PREFIX + DB, we should modify the DB name to remove the prefix > WINDOW_FUNC_PREFIX, when we are creating the read entity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HIVE-24182) Ranger authorization issue with permanent UDFs
[ https://issues.apache.org/jira/browse/HIVE-24182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HIVE-24182 started by Kishen Das. - > Ranger authorization issue with permanent UDFs > -- > > Key: HIVE-24182 > URL: https://issues.apache.org/jira/browse/HIVE-24182 > Project: Hive > Issue Type: Bug > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > We are creating the permanent function names as WINDOW_FUNC_PREFIX + > DB.PERMANENT_FUNCTION_NAME which was introduced by > https://issues.apache.org/jira/browse/HIVE-12719 . > When we populate read entities for permanent functions, we add ReadEntity > which has DB in the format WINDOW_FUNC_PREFIX + DB. Since Ranger policies are > only configured for a given database whose name is just DB and not > WINDOW_FUNC_PREFIX + DB. We should fix the DB name, when we are creating the > read entity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-24182) Ranger authorization issue with permanent UDFs
[ https://issues.apache.org/jira/browse/HIVE-24182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-24182: - Assignee: Kishen Das > Ranger authorization issue with permanent UDFs > -- > > Key: HIVE-24182 > URL: https://issues.apache.org/jira/browse/HIVE-24182 > Project: Hive > Issue Type: Bug > Components: HiveServer2 >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > We are creating the permanent function names as WINDOW_FUNC_PREFIX + > DB.PERMANENT_FUNCTION_NAME which was introduced by > https://issues.apache.org/jira/browse/HIVE-12719 . > When we populate read entities for permanent functions, we add ReadEntity > which has DB in the format WINDOW_FUNC_PREFIX + DB. Since Ranger policies are > only configured for a given database whose name is just DB and not > WINDOW_FUNC_PREFIX + DB. We should fix the DB name, when we are creating the > read entity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-24144) getIdentifierQuoteString in HiveDatabaseMetaData returns incorrect value
[
https://issues.apache.org/jira/browse/HIVE-24144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishen Das reassigned HIVE-24144:
-
Assignee: Kishen Das
> getIdentifierQuoteString in HiveDatabaseMetaData returns incorrect value
>
>
> Key: HIVE-24144
> URL: https://issues.apache.org/jira/browse/HIVE-24144
> Project: Hive
> Issue Type: Bug
> Components: JDBC
>Reporter: Jesus Camacho Rodriguez
>Assignee: Kishen Das
>Priority: Major
>
> {code}
> public String getIdentifierQuoteString() throws SQLException {
> return " ";
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (HIVE-24039) Update jquery version to mitigate CVE-2020-11023
[ https://issues.apache.org/jira/browse/HIVE-24039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-24039: - Assignee: Rajkumar Singh (was: Kishen Das) > Update jquery version to mitigate CVE-2020-11023 > > > Key: HIVE-24039 > URL: https://issues.apache.org/jira/browse/HIVE-24039 > Project: Hive > Issue Type: Bug > Components: HiveServer2 >Reporter: Rajkumar Singh >Assignee: Rajkumar Singh >Priority: Major > > there is known vulnerability in jquery version used by hive, with this jira > plan is to upgrade the jquery version 3.5.0 where it's been fixed. more > details about the vulnerability can be found here. > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11023 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HIVE-24039) Update jquery version to mitigate CVE-2020-11023
[ https://issues.apache.org/jira/browse/HIVE-24039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189782#comment-17189782 ] Kishen Das commented on HIVE-24039: --- Created a pull request -> [https://github.com/apache/hive/pull/1462] for review. > Update jquery version to mitigate CVE-2020-11023 > > > Key: HIVE-24039 > URL: https://issues.apache.org/jira/browse/HIVE-24039 > Project: Hive > Issue Type: Bug > Components: HiveServer2 >Reporter: Rajkumar Singh >Assignee: Kishen Das >Priority: Major > > there is known vulnerability in jquery version used by hive, with this jira > plan is to upgrade the jquery version 3.5.0 where it's been fixed. more > details about the vulnerability can be found here. > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11023 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HIVE-24039) Update jquery version to mitigate CVE-2020-11023
[ https://issues.apache.org/jira/browse/HIVE-24039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HIVE-24039 started by Kishen Das. - > Update jquery version to mitigate CVE-2020-11023 > > > Key: HIVE-24039 > URL: https://issues.apache.org/jira/browse/HIVE-24039 > Project: Hive > Issue Type: Bug > Components: HiveServer2 >Reporter: Rajkumar Singh >Assignee: Kishen Das >Priority: Major > > there is known vulnerability in jquery version used by hive, with this jira > plan is to upgrade the jquery version 3.5.0 where it's been fixed. more > details about the vulnerability can be found here. > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11023 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HIVE-24039) Update jquery version to mitigate CVE-2020-11023
[ https://issues.apache.org/jira/browse/HIVE-24039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das reassigned HIVE-24039: - Assignee: Kishen Das (was: Rajkumar Singh) > Update jquery version to mitigate CVE-2020-11023 > > > Key: HIVE-24039 > URL: https://issues.apache.org/jira/browse/HIVE-24039 > Project: Hive > Issue Type: Bug > Components: HiveServer2 >Reporter: Rajkumar Singh >Assignee: Kishen Das >Priority: Major > > there is known vulnerability in jquery version used by hive, with this jira > plan is to upgrade the jquery version 3.5.0 where it's been fixed. more > details about the vulnerability can be found here. > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11023 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HIVE-24092) Implement additional JDBC methods required by JDBC storage handler
[
https://issues.apache.org/jira/browse/HIVE-24092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HIVE-24092 started by Kishen Das.
-
> Implement additional JDBC methods required by JDBC storage handler
> --
>
> Key: HIVE-24092
> URL: https://issues.apache.org/jira/browse/HIVE-24092
> Project: Hive
> Issue Type: Bug
> Components: JDBC storage handler
>Reporter: Jesus Camacho Rodriguez
>Assignee: Kishen Das
>Priority: Major
>
> Calcite may rely on the following JDBC methods to generate SQL queries for
> Hive JDBC storage handler, which in the case of Hive itself, return a
> {{Method not supported}} exception. We should implement such methods:
> {code}
> nullsAreSortedAtEnd
> nullsAreSortedAtStart
> nullsAreSortedLow
> nullsAreSortedHigh
> storesLowerCaseIdentifiers
> storesLowerCaseQuotedIdentifiers
> storesMixedCaseIdentifiers
> storesMixedCaseQuotedIdentifiers
> storesUpperCaseIdentifiers
> storesUpperCaseQuotedIdentifiers
> supportsMixedCaseIdentifiers
> supportsMixedCaseQuotedIdentifiers
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (HIVE-24092) Implement additional JDBC methods required by JDBC storage handler
[
https://issues.apache.org/jira/browse/HIVE-24092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishen Das reassigned HIVE-24092:
-
Assignee: Kishen Das
> Implement additional JDBC methods required by JDBC storage handler
> --
>
> Key: HIVE-24092
> URL: https://issues.apache.org/jira/browse/HIVE-24092
> Project: Hive
> Issue Type: Bug
> Components: JDBC storage handler
>Reporter: Jesus Camacho Rodriguez
>Assignee: Kishen Das
>Priority: Major
>
> Calcite may rely on the following JDBC methods to generate SQL queries for
> Hive JDBC storage handler, which in the case of Hive itself, return a
> {{Method not supported}} exception. We should implement such methods:
> {code}
> nullsAreSortedAtEnd
> nullsAreSortedAtStart
> nullsAreSortedLow
> nullsAreSortedHigh
> storesLowerCaseIdentifiers
> storesLowerCaseQuotedIdentifiers
> storesMixedCaseIdentifiers
> storesMixedCaseQuotedIdentifiers
> storesUpperCaseIdentifiers
> storesUpperCaseQuotedIdentifiers
> supportsMixedCaseIdentifiers
> supportsMixedCaseQuotedIdentifiers
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (HIVE-23821) Send tableId in request for all the new HMS get_partition APIs
[ https://issues.apache.org/jira/browse/HIVE-23821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das resolved HIVE-23821. --- Resolution: Fixed > Send tableId in request for all the new HMS get_partition APIs > -- > > Key: HIVE-23821 > URL: https://issues.apache.org/jira/browse/HIVE-23821 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > > Table Id is needed on the HMS side to distinguish tables which have been > dropped [renamed] and recreated with the same name. In such case the tableId > is different and is used to not use the cached object to return the response. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HIVE-23820) [HS2] Send tableId in request for get_table_request API
[ https://issues.apache.org/jira/browse/HIVE-23820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishen Das updated HIVE-23820: -- Summary: [HS2] Send tableId in request for get_table_request API (was: [HS2] Send tableId in request for all the new HMS get_parition_* APIs that are in request/response form) > [HS2] Send tableId in request for get_table_request API > --- > > Key: HIVE-23820 > URL: https://issues.apache.org/jira/browse/HIVE-23820 > Project: Hive > Issue Type: Sub-task >Reporter: Kishen Das >Assignee: Kishen Das >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
