[jira] [Updated] (HIVE-27927) Iceberg: Authorize location of Iceberg data reads to tables
[ https://issues.apache.org/jira/browse/HIVE-27927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Janos Kovacs updated HIVE-27927: Summary: Iceberg: Authorize location of Iceberg data reads to tables (was: Authorize location of Iceberg data reads to tables ) > Iceberg: Authorize location of Iceberg data reads to tables > > > Key: HIVE-27927 > URL: https://issues.apache.org/jira/browse/HIVE-27927 > Project: Hive > Issue Type: Sub-task > Components: Iceberg integration >Affects Versions: 4.0.0-alpha-2 >Reporter: Janos Kovacs >Priority: Major > > This is the second phase of the solution to prevent data breach via Iceberg > data file reads in custom locations via authorizing the data locations to > tables > More details to be added... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27923) Query fails with SemanticException if column referenced with name in ORDER by
[
https://issues.apache.org/jira/browse/HIVE-27923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Riju Trivedi updated HIVE-27923:
Description:
Query fails with 'Invalid column reference' error if the column in Order by
clause is not referenced similar to Group By clause. Like below 2 queries will
compile correctly but the third one will fail.Atatched [^repro.q]
{code:java}
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`order_by_test`.`result_date`) DESC;
---Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`result_date`) AS
`process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Failure
{code}
Both column name and alias use should be supported for "ORDER BY" clause.
was:
Query fails with 'Invalid column reference' error if the column in Order by
clause is not referenced similar to Group By clause. Like below 2 queries will
compile correctly but the third one will fail.
{code:java}
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`order_by_test`.`result_date`) DESC;
---Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`result_date`) AS
`process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Failure
{code}
Both column name and alias use should be supported for "ORDER BY" clause.
Atatched [^repro.q]
> Query fails with SemanticException if column referenced with name in ORDER by
>
> ---
>
> Key: HIVE-27923
> URL: https://issues.apache.org/jira/browse/HIVE-27923
> Project: Hive
> Issue Type: Bug
> Components: Logical Optimizer
>Reporter: Riju Trivedi
>Priority: Major
> Attachments: repro.q
>
>
> Query fails with 'Invalid column reference' error if the column in Order by
> clause is not referenced similar to Group By clause. Like below 2 queries
> will compile correctly but the third one will fail.Atatched [^repro.q]
> {code:java}
> CREATE VIEW view_order_by_test AS SELECT
> to_date(`order_by_test`.`result_date`) AS `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`order_by_test`.`result_date`)
> ORDER BY to_date(`order_by_test`.`result_date`) DESC;
> ---Successful
> CREATE VIEW view_order_by_test AS SELECT to_date(`result_date`) AS
> `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`result_date`)
> ORDER BY to_date(`result_date`) DESC;
> --Successful
> CREATE VIEW view_order_by_test AS SELECT
> to_date(`order_by_test`.`result_date`) AS `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`order_by_test`.`result_date`)
> ORDER BY to_date(`result_date`) DESC;
> --Failure
> {code}
> Both column name and alias use should be supported for "ORDER BY" clause.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (HIVE-27923) Query fails with SemanticException if column referenced with name in ORDER by
[
https://issues.apache.org/jira/browse/HIVE-27923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Riju Trivedi updated HIVE-27923:
Description:
Query fails with 'Invalid column reference' error if the column in Order by
clause is not referenced similar to Group By clause. Like below 2 queries will
compile correctly but the third one will fail.
{code:java}
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`order_by_test`.`result_date`) DESC;
---Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`result_date`) AS
`process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Failure
{code}
Both column name and alias use should be supported for "ORDER BY" clause.
Atatched [^repro.q]
was:
Query fails with 'Invalid column reference' error if the column in Order by
clause is not referenced similar to Group By clause. Like below 2 queries will
compile correctly but the third one will fail.
{code:java}
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`order_by_test`.`result_date`) DESC;
---Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`result_date`) AS
`process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Failure
{code}
Both column name and alias use should be supported for "ORDER BY" clause.
Attached repro.q
> Query fails with SemanticException if column referenced with name in ORDER by
>
> ---
>
> Key: HIVE-27923
> URL: https://issues.apache.org/jira/browse/HIVE-27923
> Project: Hive
> Issue Type: Bug
> Components: Logical Optimizer
>Reporter: Riju Trivedi
>Priority: Major
> Attachments: repro.q
>
>
> Query fails with 'Invalid column reference' error if the column in Order by
> clause is not referenced similar to Group By clause. Like below 2 queries
> will compile correctly but the third one will fail.
> {code:java}
> CREATE VIEW view_order_by_test AS SELECT
> to_date(`order_by_test`.`result_date`) AS `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`order_by_test`.`result_date`)
> ORDER BY to_date(`order_by_test`.`result_date`) DESC;
> ---Successful
> CREATE VIEW view_order_by_test AS SELECT to_date(`result_date`) AS
> `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`result_date`)
> ORDER BY to_date(`result_date`) DESC;
> --Successful
> CREATE VIEW view_order_by_test AS SELECT
> to_date(`order_by_test`.`result_date`) AS `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`order_by_test`.`result_date`)
> ORDER BY to_date(`result_date`) DESC;
> --Failure
> {code}
> Both column name and alias use should be supported for "ORDER BY" clause.
> Atatched [^repro.q]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (HIVE-27923) Query fails with SemanticException if column referenced with name in ORDER by
[
https://issues.apache.org/jira/browse/HIVE-27923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Riju Trivedi updated HIVE-27923:
Description:
Query fails with 'Invalid column reference' error if the column in Order by
clause is not referenced similar to Group By clause. Like below 2 queries will
compile correctly but the third one will fail. Attached [^repro.q]
{code:java}
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`order_by_test`.`result_date`) DESC;
---Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`result_date`) AS
`process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Failure
{code}
Both column name and alias use should be supported for the "ORDER BY" clause.
was:
Query fails with 'Invalid column reference' error if the column in Order by
clause is not referenced similar to Group By clause. Like below 2 queries will
compile correctly but the third one will fail.Atatched [^repro.q]
{code:java}
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`order_by_test`.`result_date`) DESC;
---Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`result_date`) AS
`process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Failure
{code}
Both column name and alias use should be supported for "ORDER BY" clause.
> Query fails with SemanticException if column referenced with name in ORDER by
>
> ---
>
> Key: HIVE-27923
> URL: https://issues.apache.org/jira/browse/HIVE-27923
> Project: Hive
> Issue Type: Bug
> Components: Logical Optimizer
>Reporter: Riju Trivedi
>Priority: Major
> Attachments: repro.q
>
>
> Query fails with 'Invalid column reference' error if the column in Order by
> clause is not referenced similar to Group By clause. Like below 2 queries
> will compile correctly but the third one will fail. Attached [^repro.q]
> {code:java}
> CREATE VIEW view_order_by_test AS SELECT
> to_date(`order_by_test`.`result_date`) AS `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`order_by_test`.`result_date`)
> ORDER BY to_date(`order_by_test`.`result_date`) DESC;
> ---Successful
> CREATE VIEW view_order_by_test AS SELECT to_date(`result_date`) AS
> `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`result_date`)
> ORDER BY to_date(`result_date`) DESC;
> --Successful
> CREATE VIEW view_order_by_test AS SELECT
> to_date(`order_by_test`.`result_date`) AS `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`order_by_test`.`result_date`)
> ORDER BY to_date(`result_date`) DESC;
> --Failure
> {code}
> Both column name and alias use should be supported for the "ORDER BY" clause.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (HIVE-27923) Query fails with SemanticException if column referenced with name in ORDER by
[
https://issues.apache.org/jira/browse/HIVE-27923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Riju Trivedi updated HIVE-27923:
Attachment: repro.q
> Query fails with SemanticException if column referenced with name in ORDER by
>
> ---
>
> Key: HIVE-27923
> URL: https://issues.apache.org/jira/browse/HIVE-27923
> Project: Hive
> Issue Type: Bug
> Components: Logical Optimizer
>Reporter: Riju Trivedi
>Priority: Major
> Attachments: repro.q
>
>
> Query fails with 'Invalid column reference' error if the column in Order by
> clause is not referenced similar to Group By clause. Like below 2 queries
> will compile correctly but the third one will fail.
> {code:java}
> CREATE VIEW view_order_by_test AS SELECT
> to_date(`order_by_test`.`result_date`) AS `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`order_by_test`.`result_date`)
> ORDER BY to_date(`order_by_test`.`result_date`) DESC;
> ---Successful
> CREATE VIEW view_order_by_test AS SELECT to_date(`result_date`) AS
> `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`result_date`)
> ORDER BY to_date(`result_date`) DESC;
> --Successful
> CREATE VIEW view_order_by_test AS SELECT
> to_date(`order_by_test`.`result_date`) AS `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`order_by_test`.`result_date`)
> ORDER BY to_date(`result_date`) DESC;
> --Failure
> {code}
> Both column name and alias use should be supported for "ORDER BY" clause.
> Attached repro.q
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (HIVE-27923) Query fails with SemanticException if column referenced with name in ORDER by
[
https://issues.apache.org/jira/browse/HIVE-27923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Riju Trivedi updated HIVE-27923:
Description:
Query fails with 'Invalid column reference' error if the column in Order by
clause is not referenced similar to Group By clause. Like below 2 queries will
compile correctly but the third one will fail.
{code:java}
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`order_by_test`.`result_date`) DESC;
---Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`result_date`) AS
`process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Failure
{code}
Both column name and alias use should be supported for "ORDER BY" clause.
Attached repro.q
was:
Query fails with 'Invalid column reference' error if the column in Order by
clause is not referenced similar to Group By clause. Like below 2 queries will
compile correctly but the third one will fail.
{code:java}
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`order_by_test`.`result_date`) DESC;
---Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`result_date`) AS
`process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Successful
CREATE VIEW view_order_by_test AS SELECT to_date(`order_by_test`.`result_date`)
AS `process_date`,COUNT AS `count`
FROM `order_by_test`
GROUP BY to_date(`order_by_test`.`result_date`)
ORDER BY to_date(`result_date`) DESC;
--Failure
{code}
Both column name and alias use should be supported for "ORDER BY" clause.
> Query fails with SemanticException if column referenced with name in ORDER by
>
> ---
>
> Key: HIVE-27923
> URL: https://issues.apache.org/jira/browse/HIVE-27923
> Project: Hive
> Issue Type: Bug
> Components: Logical Optimizer
>Reporter: Riju Trivedi
>Priority: Major
>
> Query fails with 'Invalid column reference' error if the column in Order by
> clause is not referenced similar to Group By clause. Like below 2 queries
> will compile correctly but the third one will fail.
> {code:java}
> CREATE VIEW view_order_by_test AS SELECT
> to_date(`order_by_test`.`result_date`) AS `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`order_by_test`.`result_date`)
> ORDER BY to_date(`order_by_test`.`result_date`) DESC;
> ---Successful
> CREATE VIEW view_order_by_test AS SELECT to_date(`result_date`) AS
> `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`result_date`)
> ORDER BY to_date(`result_date`) DESC;
> --Successful
> CREATE VIEW view_order_by_test AS SELECT
> to_date(`order_by_test`.`result_date`) AS `process_date`,COUNT AS `count`
> FROM `order_by_test`
> GROUP BY to_date(`order_by_test`.`result_date`)
> ORDER BY to_date(`result_date`) DESC;
> --Failure
> {code}
> Both column name and alias use should be supported for "ORDER BY" clause.
> Attached repro.q
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (HIVE-27929) Run TPC-DS queries and validate results correctness
[ https://issues.apache.org/jira/browse/HIVE-27929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denys Kuzmenko updated HIVE-27929: -- Description: test branch: *branch-4.0* > Run TPC-DS queries and validate results correctness > --- > > Key: HIVE-27929 > URL: https://issues.apache.org/jira/browse/HIVE-27929 > Project: Hive > Issue Type: Sub-task >Reporter: Denys Kuzmenko >Assignee: Dmitriy Fingerman >Priority: Major > > test branch: *branch-4.0* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (HIVE-27929) Run TPC-DS queries and validate results correctness
[ https://issues.apache.org/jira/browse/HIVE-27929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denys Kuzmenko reassigned HIVE-27929: - Assignee: Dmitriy Fingerman > Run TPC-DS queries and validate results correctness > --- > > Key: HIVE-27929 > URL: https://issues.apache.org/jira/browse/HIVE-27929 > Project: Hive > Issue Type: Sub-task >Reporter: Denys Kuzmenko >Assignee: Dmitriy Fingerman >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (HIVE-27929) Run TPC-DS queries and validate results correctness
[ https://issues.apache.org/jira/browse/HIVE-27929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792141#comment-17792141 ] Denys Kuzmenko commented on HIVE-27929: --- cc [~seonggon], [~glapark] in case you'll have some findings > Run TPC-DS queries and validate results correctness > --- > > Key: HIVE-27929 > URL: https://issues.apache.org/jira/browse/HIVE-27929 > Project: Hive > Issue Type: Sub-task >Reporter: Denys Kuzmenko >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27921) Prepare for Hive 4.0.0 Release
[ https://issues.apache.org/jira/browse/HIVE-27921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denys Kuzmenko updated HIVE-27921: -- Issue Type: Task (was: New Feature) > Prepare for Hive 4.0.0 Release > -- > > Key: HIVE-27921 > URL: https://issues.apache.org/jira/browse/HIVE-27921 > Project: Hive > Issue Type: Task > Components: Hive >Affects Versions: 4.0.0 >Reporter: Denys Kuzmenko >Assignee: Denys Kuzmenko >Priority: Major > > That is an Umbrella Jira to track the activity around Hive 4.0.0 release. > *Please note that this is an Open forum and every input from the community is > welcomed.* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (HIVE-27921) Prepare for Hive 4.0.0 Release
[ https://issues.apache.org/jira/browse/HIVE-27921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denys Kuzmenko reassigned HIVE-27921: - Assignee: Denys Kuzmenko > Prepare for Hive 4.0.0 Release > -- > > Key: HIVE-27921 > URL: https://issues.apache.org/jira/browse/HIVE-27921 > Project: Hive > Issue Type: New Feature > Components: Hive >Affects Versions: 4.0.0 >Reporter: Denys Kuzmenko >Assignee: Denys Kuzmenko >Priority: Major > > That is an Umbrella Jira to track the activity around Hive 4.0.0 release. > *Please note that this is an Open forum and every input from the community is > welcomed.* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (HIVE-27928) Update development version in a master branch
[ https://issues.apache.org/jira/browse/HIVE-27928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denys Kuzmenko reassigned HIVE-27928: - Assignee: Denys Kuzmenko > Update development version in a master branch > - > > Key: HIVE-27928 > URL: https://issues.apache.org/jira/browse/HIVE-27928 > Project: Hive > Issue Type: Sub-task >Reporter: Denys Kuzmenko >Assignee: Denys Kuzmenko >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HIVE-27929) Run TPC-DS queries and validate results correctness
Denys Kuzmenko created HIVE-27929: - Summary: Run TPC-DS queries and validate results correctness Key: HIVE-27929 URL: https://issues.apache.org/jira/browse/HIVE-27929 Project: Hive Issue Type: Sub-task Reporter: Denys Kuzmenko -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (HIVE-27928) Update development version in a master branch
[ https://issues.apache.org/jira/browse/HIVE-27928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HIVE-27928 started by Denys Kuzmenko. - > Update development version in a master branch > - > > Key: HIVE-27928 > URL: https://issues.apache.org/jira/browse/HIVE-27928 > Project: Hive > Issue Type: Sub-task >Reporter: Denys Kuzmenko >Assignee: Denys Kuzmenko >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27928) Update development version in a master branch
[ https://issues.apache.org/jira/browse/HIVE-27928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated HIVE-27928: -- Labels: pull-request-available (was: ) > Update development version in a master branch > - > > Key: HIVE-27928 > URL: https://issues.apache.org/jira/browse/HIVE-27928 > Project: Hive > Issue Type: Sub-task >Reporter: Denys Kuzmenko >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (HIVE-27741) Invalid timezone value in to_utc_timestamp() is treated as UTC which can lead to data consistency issues
[
https://issues.apache.org/jira/browse/HIVE-27741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HIVE-27741 started by Zoltán Rátkai.
> Invalid timezone value in to_utc_timestamp() is treated as UTC which can lead
> to data consistency issues
>
>
> Key: HIVE-27741
> URL: https://issues.apache.org/jira/browse/HIVE-27741
> Project: Hive
> Issue Type: Sub-task
>Affects Versions: 4.0.0-beta-1
>Reporter: Janos Kovacs
>Assignee: Zoltán Rátkai
>Priority: Major
>
> When the timezone specified in the *to_utc_timestamp()* function is not
> valid, it still treated as UTC instead of throwing an error. If the user
> accidentally made a typo - e.g. America/Los{color:#ff}*t*{color}_Angeles,
> the query runs successfully returning an invalid converted value which can
> lead to data consistency issues.
> Repro code:
> {noformat}
> docker rm -f hive4
> export HIVE_VERSION=4.0.0-beta-2-SNAPSHOT
> export HS2_ENV_TZ="Europe/Budapest"
> export HS2_USER_TZ=${HS2_ENV_TZ}
> export HIVE_LOCAL_TZ="America/Los_Angeles"
> export HS2_OPTS="-Duser.timezone=$HS2_USER_TZ
> -Dhive.local.time.zone=$HIVE_LOCAL_TZ"
> export HS2_OPTS="$HS2_OPTS
> -Dhive.server2.tez.initialize.default.sessions=false"
> docker run -d -p 1:1 -p 10001:10001 -p 10002:10002 --env
> TZ=${HS2_ENV_TZ} --env SERVICE_OPTS=${HS2_OPTS} --env
> SERVICE_NAME=hiveserver2 --name hive4 apache/hive:${HIVE_VERSION}
> docker exec -it hive4 beeline -u 'jdbc:hive2://localhost:1/' -e "
> SELECT '\${env:TZ}' as \`env:TZ\`,
>'\${system:user.timezone}' as \`system:user.timezone\`,
>'\${hiveconf:hive.local.time.zone}' as
> \`hiveconf:hive.local.time.zone\`;
> DROP TABLE IF EXISTS timestamptest;
> CREATE TABLE timestamptest (
> ts timestamp,
> tz timestamp with local time zone
> ) STORED AS TEXTFILE;
> INSERT INTO timestamptest select TIMESTAMP'2016-01-03
> 12:26:34',TIMESTAMPLOCALTZ'2016-01-03 12:26:34 America/Los_Angeles';
> SELECT
> tzas orig,
> to_utc_timestamp(tz, 'America/Los_Angeles') as utc_correct_tz,
> to_utc_timestamp(tz, 'Europe/HereIsATypo')as utc_incorrect_tz,
> to_utc_timestamp(tz, 'LOCAL') as
> utc_local_aslo_incorrect_tz,
> to_utc_timestamp(tz, 'UTC') as utc_tz
> FROM timestamptest;
> "
> {noformat}
>
> The results are:
> {noformat}
> +--+---++
> | env:tz | system:user.timezone | hiveconf:hive.local.time.zone |
> +--+---++
> | Europe/Budapest | Europe/Budapest | America/Los_Angeles|
> +--+---++
> ++++--++
> |orig| utc_correct_tz |
> utc_incorrect_tz| utc_local_aslo_incorrect_tz | utc_tz |
> ++++--++
> | 2016-01-03 12:26:34.0 America/Los_Angeles | 2016-01-03 20:26:34.0 |
> 2016-01-03 12:26:34.0 | 2016-01-03 12:26:34.0| 2016-01-03 12:26:34.0
> |
> ++++--++
> {noformat}
> Note:
> * the invalid timezone - utc_incorrect_tz - is treated as UTC
> * also note that LOCAL is also treated as UTC which in fact should be
> treated as system's timezone, but as LOCAL is also an invalid timezone value
> in hive4, ut becomes UTC just like any other invalid and/or typo timezone
> values (see HIVE-27742)
>
> Hive should throw an Exception in that case to let the user know that the
> provided timezone is wrong - at least this should be configurable, e.g. via
> something like {*}hive.strict.time.zone.check{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (HIVE-27926) Allow restricting Iceberg data file reads to table location
[
https://issues.apache.org/jira/browse/HIVE-27926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ayush Saxena reassigned HIVE-27926:
---
Assignee: Ayush Saxena (was: Ayushmaan Saxena)
> Allow restricting Iceberg data file reads to table location
> ---
>
> Key: HIVE-27926
> URL: https://issues.apache.org/jira/browse/HIVE-27926
> Project: Hive
> Issue Type: Sub-task
> Components: Iceberg integration
>Affects Versions: 4.0.0-alpha-2
>Reporter: Janos Kovacs
>Assignee: Ayush Saxena
>Priority: Blocker
>
> As the first quick solution there should be a configuration flag to allow us
> to restrict Iceberg reads to data files located only inside of the table
> locations.
> e.g. with the following definition
> {noformat}
> CREATE EXTERNAL TABLE default.iceloc1 (txt string, secret string)
> STORED BY ICEBERG
> LOCATION '/data/hive/external/iceloc1/'
> TBLPROPERTIES (
> 'external.table.purge'='true',
> 'write.metadata.path'='/data/ice/meta/iceloc1/',
> 'write.data.path'='/data/ice/data/iceloc1/');
> {noformat}
> The restricted location should be
> {noformat}
> /data/hive/external/iceloc1/
> {noformat}
> Note: this configuration should not be enabled by default as this breaks
> Iceberg's functionality storing data files in different locations and would
> only be useful when users use iceberg only as standard external tables with
> meta+data under table location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (HIVE-27926) Iceberg: Allow restricting Iceberg data file reads to table location
[
https://issues.apache.org/jira/browse/HIVE-27926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ayush Saxena updated HIVE-27926:
Summary: Iceberg: Allow restricting Iceberg data file reads to table
location (was: Allow restricting Iceberg data file reads to table location)
> Iceberg: Allow restricting Iceberg data file reads to table location
>
>
> Key: HIVE-27926
> URL: https://issues.apache.org/jira/browse/HIVE-27926
> Project: Hive
> Issue Type: Sub-task
> Components: Iceberg integration
>Affects Versions: 4.0.0-alpha-2
>Reporter: Janos Kovacs
>Assignee: Ayush Saxena
>Priority: Blocker
>
> As the first quick solution there should be a configuration flag to allow us
> to restrict Iceberg reads to data files located only inside of the table
> locations.
> e.g. with the following definition
> {noformat}
> CREATE EXTERNAL TABLE default.iceloc1 (txt string, secret string)
> STORED BY ICEBERG
> LOCATION '/data/hive/external/iceloc1/'
> TBLPROPERTIES (
> 'external.table.purge'='true',
> 'write.metadata.path'='/data/ice/meta/iceloc1/',
> 'write.data.path'='/data/ice/data/iceloc1/');
> {noformat}
> The restricted location should be
> {noformat}
> /data/hive/external/iceloc1/
> {noformat}
> Note: this configuration should not be enabled by default as this breaks
> Iceberg's functionality storing data files in different locations and would
> only be useful when users use iceberg only as standard external tables with
> meta+data under table location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (HIVE-27928) Update development version in a master branch
Denys Kuzmenko created HIVE-27928: - Summary: Update development version in a master branch Key: HIVE-27928 URL: https://issues.apache.org/jira/browse/HIVE-27928 Project: Hive Issue Type: Sub-task Reporter: Denys Kuzmenko -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27921) Prepare for Hive 4.0.0 Release
[ https://issues.apache.org/jira/browse/HIVE-27921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denys Kuzmenko updated HIVE-27921: -- Issue Type: New Feature (was: Task) > Prepare for Hive 4.0.0 Release > -- > > Key: HIVE-27921 > URL: https://issues.apache.org/jira/browse/HIVE-27921 > Project: Hive > Issue Type: New Feature > Components: Hive >Affects Versions: 4.0.0 >Reporter: Denys Kuzmenko >Priority: Major > > That is an Umbrella Jira to track the activity around Hive 4.0.0 release. > *Please note that this is an Open forum and every input from the community is > welcomed.* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HIVE-27927) Authorize location of Iceberg data reads to tables
Janos Kovacs created HIVE-27927: --- Summary: Authorize location of Iceberg data reads to tables Key: HIVE-27927 URL: https://issues.apache.org/jira/browse/HIVE-27927 Project: Hive Issue Type: Sub-task Components: Iceberg integration Affects Versions: 4.0.0-alpha-2 Reporter: Janos Kovacs This is the second phase of the solution to prevent data breach via Iceberg data file reads in custom locations via authorizing the data locations to tables More details to be added... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HIVE-27926) Allow restricting Iceberg data file reads to table location
Janos Kovacs created HIVE-27926:
---
Summary: Allow restricting Iceberg data file reads to table
location
Key: HIVE-27926
URL: https://issues.apache.org/jira/browse/HIVE-27926
Project: Hive
Issue Type: Sub-task
Components: Iceberg integration
Affects Versions: 4.0.0-alpha-2
Reporter: Janos Kovacs
Assignee: Ayushmaan Saxena
As the first quick solution there should be a configuration flag to allow us to
restrict Iceberg reads to data files located only inside of the table locations.
e.g. with the following definition
{noformat}
CREATE EXTERNAL TABLE default.iceloc1 (txt string, secret string)
STORED BY ICEBERG
LOCATION '/data/hive/external/iceloc1/'
TBLPROPERTIES (
'external.table.purge'='true',
'write.metadata.path'='/data/ice/meta/iceloc1/',
'write.data.path'='/data/ice/data/iceloc1/');
{noformat}
The restricted location should be
{noformat}
/data/hive/external/iceloc1/
{noformat}
Note: this configuration should not be enabled by default as this breaks
Iceberg's functionality storing data files in different locations and would
only be useful when users use iceberg only as standard external tables with
meta+data under table location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (HIVE-27714) Iceberg: metadata location overrides can cause data breach - handling default locations
[
https://issues.apache.org/jira/browse/HIVE-27714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792098#comment-17792098
]
Ayush Saxena commented on HIVE-27714:
-
Committed to master.
Thanx [~dkuzmenko] for the review!!!
> Iceberg: metadata location overrides can cause data breach - handling default
> locations
>
>
> Key: HIVE-27714
> URL: https://issues.apache.org/jira/browse/HIVE-27714
> Project: Hive
> Issue Type: Sub-task
> Components: Authorization, Iceberg integration
>Affects Versions: 4.0.0-alpha-2
>Reporter: Janos Kovacs
>Assignee: Ayush Saxena
>Priority: Critical
> Labels: check, pull-request-available
>
> With current Iceberg location authorization one explicit ranger policy is
> required for every tables to prevent the cross-reference of metadata_location
> exploit as any wildcard based policy to cover set of tables would open up
> cross-referencing locations between tables covert by the wildcard.
> This is nearly impossible in a production environment.
> The proposal is to handle the Iceberg table RWStorage authorization a
> different way when the table is created/altered with it's default location as
> in this case there is no attempt for cross-referencing another table. There
> are two options for this:
> When?
> * If no custom metadata_location is set/given in the CREATE/ALTER calls
> * If the given metadata_locaiton's path (e.g. without the metadata json file
> name) is the same as the current metadata_location's path in the ALTER calls
> * If the given metadata_location's path set/given in CREATE/ALTEER calls is
> the same as the default location would be for the table based on the
> warehouse and/or database locations
> What
> # Either do not call the RWStorage Authorizer for this case
> # Or set the location to a constant value that can be easily handled with
> one single access policy on the Authorizer side
> Pros/Cons:
> * Option-1 would not call authorizer so it would not generate an audit even
> for these on RWStorage level policies but it would omit the Authorization
> step so it would be more performant
> * Option-2 would end up in the Authorizer which means also would generate an
> audit event. It also needs a pre-agreed constant for such cases that can be
> differentiated from normal custom location based authorizations.
> If the Option-2 is chosen:
> * The following policy syntax could be used for custom locations:
> {noformat}
> iceberg://mydatabase/mytable/snapshot=/my/custom/location/whatever/*
> {noformat}
> * While the pre-agreed default location constant based policy format could
> be:
> {noformat}
> iceberg://*/*/snapshot=default_location {noformat}
>
> There could be even a new property introduced to decide if the Authorization
> for default locations should be skipped at-all, or not (and use the e.g.
> snapshot=default_location constant). This way everyone can decide whether
> audit events or the performance w/o the authorization step are preferred.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (HIVE-27714) Iceberg: metadata location overrides can cause data breach - handling default locations
[
https://issues.apache.org/jira/browse/HIVE-27714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ayush Saxena resolved HIVE-27714.
-
Fix Version/s: 4.0.0
Resolution: Fixed
> Iceberg: metadata location overrides can cause data breach - handling default
> locations
>
>
> Key: HIVE-27714
> URL: https://issues.apache.org/jira/browse/HIVE-27714
> Project: Hive
> Issue Type: Sub-task
> Components: Authorization, Iceberg integration
>Affects Versions: 4.0.0-alpha-2
>Reporter: Janos Kovacs
>Assignee: Ayush Saxena
>Priority: Critical
> Labels: check, pull-request-available
> Fix For: 4.0.0
>
>
> With current Iceberg location authorization one explicit ranger policy is
> required for every tables to prevent the cross-reference of metadata_location
> exploit as any wildcard based policy to cover set of tables would open up
> cross-referencing locations between tables covert by the wildcard.
> This is nearly impossible in a production environment.
> The proposal is to handle the Iceberg table RWStorage authorization a
> different way when the table is created/altered with it's default location as
> in this case there is no attempt for cross-referencing another table. There
> are two options for this:
> When?
> * If no custom metadata_location is set/given in the CREATE/ALTER calls
> * If the given metadata_locaiton's path (e.g. without the metadata json file
> name) is the same as the current metadata_location's path in the ALTER calls
> * If the given metadata_location's path set/given in CREATE/ALTEER calls is
> the same as the default location would be for the table based on the
> warehouse and/or database locations
> What
> # Either do not call the RWStorage Authorizer for this case
> # Or set the location to a constant value that can be easily handled with
> one single access policy on the Authorizer side
> Pros/Cons:
> * Option-1 would not call authorizer so it would not generate an audit even
> for these on RWStorage level policies but it would omit the Authorization
> step so it would be more performant
> * Option-2 would end up in the Authorizer which means also would generate an
> audit event. It also needs a pre-agreed constant for such cases that can be
> differentiated from normal custom location based authorizations.
> If the Option-2 is chosen:
> * The following policy syntax could be used for custom locations:
> {noformat}
> iceberg://mydatabase/mytable/snapshot=/my/custom/location/whatever/*
> {noformat}
> * While the pre-agreed default location constant based policy format could
> be:
> {noformat}
> iceberg://*/*/snapshot=default_location {noformat}
>
> There could be even a new property introduced to decide if the Authorization
> for default locations should be skipped at-all, or not (and use the e.g.
> snapshot=default_location constant). This way everyone can decide whether
> audit events or the performance w/o the authorization step are preferred.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (HIVE-27791) Eliminate totalSize check from test
[ https://issues.apache.org/jira/browse/HIVE-27791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated HIVE-27791: -- Labels: pull-request-available (was: ) > Eliminate totalSize check from test > --- > > Key: HIVE-27791 > URL: https://issues.apache.org/jira/browse/HIVE-27791 > Project: Hive > Issue Type: Improvement >Reporter: Zoltán Rátkai >Assignee: Zoltán Rátkai >Priority: Major > Labels: pull-request-available > > As discussed in this ticket, totalSize checks need to be eliminated from > tests: > https://github.com/apache/hive/pull/4690 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27893) Do not allow user to set hive.metastore.batch.retrieve.max property to < 1
[ https://issues.apache.org/jira/browse/HIVE-27893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikram Ahuja updated HIVE-27893: Description: Currently there is no Validation for the property hive.metastore.batch.retrieve.max. In case if it is ever set to <= 0, PartitionIterable will throw up NoSuchElement Exception because the batch size will be 0 there. Adding a range validator as the part of this Jira to keep the lower bound value of hive.metastore.batch.retrieve.max to be 1. Also blocking PartitionIterable call if any user/client ever calls the constructor directly with batch size <1. (was: Currently there is no Validation for the property hive.metastore.batch.retrieve.max. In case if it is ever set to <= 0 PartitionIterable will throw up NoSuchElement Exception because the batch size will be 0 there. Adding a range validator as the part of this Jira to keep the lower bound value of hive.metastore.batch.retrieve.max to be 1. Also blocking PartitionIterable call if any user/client ever calls the constructor directly with batch size <1.) > Do not allow user to set hive.metastore.batch.retrieve.max property to < 1 > -- > > Key: HIVE-27893 > URL: https://issues.apache.org/jira/browse/HIVE-27893 > Project: Hive > Issue Type: Bug >Reporter: Vikram Ahuja >Assignee: Vikram Ahuja >Priority: Major > Labels: pull-request-available > > Currently there is no Validation for the property > hive.metastore.batch.retrieve.max. In case if it is ever set to <= 0, > PartitionIterable will throw up NoSuchElement Exception because the batch > size will be 0 there. Adding a range validator as the part of this Jira to > keep the lower bound value of hive.metastore.batch.retrieve.max to be 1. Also > blocking PartitionIterable call if any user/client ever calls the constructor > directly with batch size <1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27925) HiveConf: unify ConfVars enum and use underscore for better readability
[ https://issues.apache.org/jira/browse/HIVE-27925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] László Bodor updated HIVE-27925: Description: When I read something like "[BASICSTATSTASKSMAXTHREADSFACTOR|https://github.com/apache/hive/blob/70f34e27349dccf5fabbfc6c63e63c7be0785360/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L753]; I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) imagine what if we have vars like [HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL|https://github.com/apache/hive/blob/70f34e27349dccf5fabbfc6c63e63c7be0785360/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L1921] without underscores...okay, let me help, it is: HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D please let's fix this in 4.0.0 was: When I read something like "[BASICSTATSTASKSMAXTHREADSFACTOR|https://github.com/apache/hive/blob/70f34e27349dccf5fabbfc6c63e63c7be0785360/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L753]; I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) imagine what if we have vars like HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores...okay, let me help, it is: HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D please let's fix this in 4.0.0 > HiveConf: unify ConfVars enum and use underscore for better readability > > > Key: HIVE-27925 > URL: https://issues.apache.org/jira/browse/HIVE-27925 > Project: Hive > Issue Type: Improvement >Reporter: László Bodor >Assignee: Kokila N >Priority: Major > Fix For: 4.0.0 > > > When I read something like > "[BASICSTATSTASKSMAXTHREADSFACTOR|https://github.com/apache/hive/blob/70f34e27349dccf5fabbfc6c63e63c7be0785360/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L753]; > I feel someone in the world laughs out loud thinking of me struggling. I can > read it, but I hate it :) imagine what if we have vars like > [HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL|https://github.com/apache/hive/blob/70f34e27349dccf5fabbfc6c63e63c7be0785360/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L1921] > without underscores...okay, let me help, it is: > HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D > please let's fix this in 4.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27893) Do not allow user to set hive.metastore.batch.retrieve.max property to < 1
[ https://issues.apache.org/jira/browse/HIVE-27893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikram Ahuja updated HIVE-27893: Description: Currently there is no Validation for the property hive.metastore.batch.retrieve.max. In case if it is ever set to <= 0 PartitionIterable will throw up NoSuchElement Exception because the batch size will be 0 there. Adding a range validator as the part of this Jira to keep the lower bound value of hive.metastore.batch.retrieve.max to be 1. Also blocking PartitionIterable call if any user/client ever calls the constructor directly with batch size <1. (was: Currently there is no Validation for the property hive.metastore.batch.retrieve.max. In case if it is ever set to <= 0 PartitionIterable will throw up NoSuchElement Exception because the batch size will be 0 there. Adding a range validator as the part of this Jira to keep the value of ) > Do not allow user to set hive.metastore.batch.retrieve.max property to < 1 > -- > > Key: HIVE-27893 > URL: https://issues.apache.org/jira/browse/HIVE-27893 > Project: Hive > Issue Type: Bug >Reporter: Vikram Ahuja >Assignee: Vikram Ahuja >Priority: Major > Labels: pull-request-available > > Currently there is no Validation for the property > hive.metastore.batch.retrieve.max. In case if it is ever set to <= 0 > PartitionIterable will throw up NoSuchElement Exception because the batch > size will be 0 there. Adding a range validator as the part of this Jira to > keep the lower bound value of hive.metastore.batch.retrieve.max to be 1. Also > blocking PartitionIterable call if any user/client ever calls the constructor > directly with batch size <1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27893) Do not allow user to set hive.metastore.batch.retrieve.max property to < 1
[ https://issues.apache.org/jira/browse/HIVE-27893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikram Ahuja updated HIVE-27893: Description: Currently there is no Validation for the property hive.metastore.batch.retrieve.max. In case if it is ever set to <= 0 PartitionIterable will throw up NoSuchElement Exception because the batch size will be 0 there. Adding a range validator as the part of this Jira to keep the value of (was: Currently there is no Validation for the property ) > Do not allow user to set hive.metastore.batch.retrieve.max property to < 1 > -- > > Key: HIVE-27893 > URL: https://issues.apache.org/jira/browse/HIVE-27893 > Project: Hive > Issue Type: Bug >Reporter: Vikram Ahuja >Assignee: Vikram Ahuja >Priority: Major > Labels: pull-request-available > > Currently there is no Validation for the property > hive.metastore.batch.retrieve.max. In case if it is ever set to <= 0 > PartitionIterable will throw up NoSuchElement Exception because the batch > size will be 0 there. Adding a range validator as the part of this Jira to > keep the value of -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27925) HiveConf: unify ConfVars enum and use underscore for better readability
[ https://issues.apache.org/jira/browse/HIVE-27925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] László Bodor updated HIVE-27925: Fix Version/s: 4.0.0 > HiveConf: unify ConfVars enum and use underscore for better readability > > > Key: HIVE-27925 > URL: https://issues.apache.org/jira/browse/HIVE-27925 > Project: Hive > Issue Type: Improvement >Reporter: László Bodor >Assignee: Kokila N >Priority: Major > Fix For: 4.0.0 > > > When I read something like > "[BASICSTATSTASKSMAXTHREADSFACTOR|https://github.com/apache/hive/blob/70f34e27349dccf5fabbfc6c63e63c7be0785360/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L753]; > I feel someone in the world laughs out loud thinking of me struggling. I can > read it, but I hate it :) imagine what if we have vars like > HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without > underscores...okay, let me help, it is: > HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27893) Do not allow user to set hive.metastore.batch.retrieve.max property to < 1
[ https://issues.apache.org/jira/browse/HIVE-27893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikram Ahuja updated HIVE-27893: Description: Currently there is no Validation for the property > Do not allow user to set hive.metastore.batch.retrieve.max property to < 1 > -- > > Key: HIVE-27893 > URL: https://issues.apache.org/jira/browse/HIVE-27893 > Project: Hive > Issue Type: Bug >Reporter: Vikram Ahuja >Assignee: Vikram Ahuja >Priority: Major > Labels: pull-request-available > > Currently there is no Validation for the property -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27925) HiveConf: unify ConfVars enum and use underscore for better readability
[ https://issues.apache.org/jira/browse/HIVE-27925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] László Bodor updated HIVE-27925: Description: When I read something like "[BASICSTATSTASKSMAXTHREADSFACTOR|https://github.com/apache/hive/blob/70f34e27349dccf5fabbfc6c63e63c7be0785360/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L753]; I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) imagine what if we have vars like HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores...okay, let me help, it is: HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D please let's fix this in 4.0.0 was:When I read something like "[BASICSTATSTASKSMAXTHREADSFACTOR|https://github.com/apache/hive/blob/70f34e27349dccf5fabbfc6c63e63c7be0785360/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L753]; I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) imagine what if we have vars like HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores...okay, let me help, it is: HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D > HiveConf: unify ConfVars enum and use underscore for better readability > > > Key: HIVE-27925 > URL: https://issues.apache.org/jira/browse/HIVE-27925 > Project: Hive > Issue Type: Improvement >Reporter: László Bodor >Assignee: Kokila N >Priority: Major > Fix For: 4.0.0 > > > When I read something like > "[BASICSTATSTASKSMAXTHREADSFACTOR|https://github.com/apache/hive/blob/70f34e27349dccf5fabbfc6c63e63c7be0785360/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L753]; > I feel someone in the world laughs out loud thinking of me struggling. I can > read it, but I hate it :) imagine what if we have vars like > HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without > underscores...okay, let me help, it is: > HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D > please let's fix this in 4.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27925) HiveConf: unify ConfVars enum and use underscore for better readability
[ https://issues.apache.org/jira/browse/HIVE-27925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] László Bodor updated HIVE-27925: Description: When I read something like "[BASICSTATSTASKSMAXTHREADSFACTOR|https://github.com/apache/hive/blob/70f34e27349dccf5fabbfc6c63e63c7be0785360/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L753]; I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) imagine what if we have vars like HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores, let me help, it's HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D (was: When I read something like "BASICSTATSTASKSMAXTHREADSFACTOR" I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) imagine what if we have vars like HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores, let me help, it's HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D) > HiveConf: unify ConfVars enum and use underscore for better readability > > > Key: HIVE-27925 > URL: https://issues.apache.org/jira/browse/HIVE-27925 > Project: Hive > Issue Type: Improvement >Reporter: László Bodor >Assignee: Kokila N >Priority: Major > > When I read something like > "[BASICSTATSTASKSMAXTHREADSFACTOR|https://github.com/apache/hive/blob/70f34e27349dccf5fabbfc6c63e63c7be0785360/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L753]; > I feel someone in the world laughs out loud thinking of me struggling. I can > read it, but I hate it :) imagine what if we have vars like > HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without > underscores, let me help, it's > HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27925) HiveConf: unify ConfVars enum and use underscore for better readability
[ https://issues.apache.org/jira/browse/HIVE-27925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] László Bodor updated HIVE-27925: Description: When I read something like "[BASICSTATSTASKSMAXTHREADSFACTOR|https://github.com/apache/hive/blob/70f34e27349dccf5fabbfc6c63e63c7be0785360/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L753]; I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) imagine what if we have vars like HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores...okay, let me help, it is: HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D (was: When I read something like "[BASICSTATSTASKSMAXTHREADSFACTOR|https://github.com/apache/hive/blob/70f34e27349dccf5fabbfc6c63e63c7be0785360/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L753]; I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) imagine what if we have vars like HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores, let me help, it's HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D) > HiveConf: unify ConfVars enum and use underscore for better readability > > > Key: HIVE-27925 > URL: https://issues.apache.org/jira/browse/HIVE-27925 > Project: Hive > Issue Type: Improvement >Reporter: László Bodor >Assignee: Kokila N >Priority: Major > > When I read something like > "[BASICSTATSTASKSMAXTHREADSFACTOR|https://github.com/apache/hive/blob/70f34e27349dccf5fabbfc6c63e63c7be0785360/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L753]; > I feel someone in the world laughs out loud thinking of me struggling. I can > read it, but I hate it :) imagine what if we have vars like > HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without > underscores...okay, let me help, it is: > HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (HIVE-27925) HiveConf: unify ConfVars enum and use underscore for better readability
[ https://issues.apache.org/jira/browse/HIVE-27925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kokila N reassigned HIVE-27925: --- Assignee: Kokila N > HiveConf: unify ConfVars enum and use underscore for better readability > > > Key: HIVE-27925 > URL: https://issues.apache.org/jira/browse/HIVE-27925 > Project: Hive > Issue Type: Improvement >Reporter: László Bodor >Assignee: Kokila N >Priority: Major > > When I read something like "BASICSTATSTASKSMAXTHREADSFACTOR" I feel someone > in the world laughs out loud thinking of me struggling. I can read it, but I > hate it :) imagine what if we have vars like > HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without > underscores, let me help, it's > HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27925) HiveConf: unify ConfVars enum and use underscore for better readability
[ https://issues.apache.org/jira/browse/HIVE-27925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] László Bodor updated HIVE-27925: Description: When I read something like "BASICSTATSTASKSMAXTHREADSFACTOR" I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) imagine what if we have vars like HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores, let me help, it's HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D (was: When I read something like "BASICSTATSTASKSMAXTHREADSFACTOR" I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) imagine what if we have vars like HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores, let help, it's HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D) > HiveConf: unify ConfVars enum and use underscore for better readability > > > Key: HIVE-27925 > URL: https://issues.apache.org/jira/browse/HIVE-27925 > Project: Hive > Issue Type: Improvement >Reporter: László Bodor >Priority: Major > > When I read something like "BASICSTATSTASKSMAXTHREADSFACTOR" I feel someone > in the world laughs out loud thinking of me struggling. I can read it, but I > hate it :) imagine what if we have vars like > HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without > underscores, let me help, it's > HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27925) HiveConf: unify ConfVars enum and use underscore for better readability
[ https://issues.apache.org/jira/browse/HIVE-27925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] László Bodor updated HIVE-27925: Description: When I read something like "BASICSTATSTASKSMAXTHREADSFACTOR" I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) imagine what if we have vars like HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores, let help, it's HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D (was: When I read something like "BASICSTATSTASKSMAXTHREADSFACTOR" I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) imagine what if we have vars like HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores.) > HiveConf: unify ConfVars enum and use underscore for better readability > > > Key: HIVE-27925 > URL: https://issues.apache.org/jira/browse/HIVE-27925 > Project: Hive > Issue Type: Improvement >Reporter: László Bodor >Priority: Major > > When I read something like "BASICSTATSTASKSMAXTHREADSFACTOR" I feel someone > in the world laughs out loud thinking of me struggling. I can read it, but I > hate it :) imagine what if we have vars like > HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without > underscores, let help, it's > HIVEMATERIALIZEDVIEWENABLEAUTOREWRITINGSUBQUERYSQL :D -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27925) HiveConf: unify ConfVars enum and use underscore for better readability
[ https://issues.apache.org/jira/browse/HIVE-27925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] László Bodor updated HIVE-27925: Description: When I read something like "BASICSTATSTASKSMAXTHREADSFACTOR" I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) imagine what if we have vars like HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores. (was: When I read something like "BASICSTATSTASKSMAXTHREADSFACTOR" I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) image what if we have vars like HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores.) > HiveConf: unify ConfVars enum and use underscore for better readability > > > Key: HIVE-27925 > URL: https://issues.apache.org/jira/browse/HIVE-27925 > Project: Hive > Issue Type: Improvement >Reporter: László Bodor >Priority: Major > > When I read something like "BASICSTATSTASKSMAXTHREADSFACTOR" I feel someone > in the world laughs out loud thinking of me struggling. I can read it, but I > hate it :) imagine what if we have vars like > HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-27925) HiveConf: unify ConfVars enum and use underscore for better readability
[ https://issues.apache.org/jira/browse/HIVE-27925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] László Bodor updated HIVE-27925: Description: When I read something like "BASICSTATSTASKSMAXTHREADSFACTOR" I feel someone in the world laughs out loud thinking of me struggling. I can read it, but I hate it :) image what if we have vars like HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores. > HiveConf: unify ConfVars enum and use underscore for better readability > > > Key: HIVE-27925 > URL: https://issues.apache.org/jira/browse/HIVE-27925 > Project: Hive > Issue Type: Improvement >Reporter: László Bodor >Priority: Major > > When I read something like "BASICSTATSTASKSMAXTHREADSFACTOR" I feel someone > in the world laughs out loud thinking of me struggling. I can read it, but I > hate it :) image what if we have vars like > HIVE_MATERIALIZED_VIEW_ENABLE_AUTO_REWRITING_SUBQUERY_SQL without underscores. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HIVE-27925) HiveConf: unify ConfVars enum and use underscore for better readability
László Bodor created HIVE-27925: --- Summary: HiveConf: unify ConfVars enum and use underscore for better readability Key: HIVE-27925 URL: https://issues.apache.org/jira/browse/HIVE-27925 Project: Hive Issue Type: Improvement Reporter: László Bodor -- This message was sent by Atlassian Jira (v8.20.10#820010)
