[jira] [Resolved] (PHOENIX-7156) Run integration tests based on @Category
[ https://issues.apache.org/jira/browse/PHOENIX-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajeshbabu Chintaguntla resolved PHOENIX-7156. -- Assignee: Nikita Pande Resolution: Fixed Committed to 5.1 branch. > Run integration tests based on @Category > > > Key: PHOENIX-7156 > URL: https://issues.apache.org/jira/browse/PHOENIX-7156 > Project: Phoenix > Issue Type: Improvement >Reporter: Nikita Pande >Assignee: Nikita Pande >Priority: Major > Fix For: 5.2.0, 5.1.4 > > > Following are the categories described in integration tests of phoenix. > * ParallelStatsEnabledTests > * ParallelStatsDisabledTests > * NeedTheirOwnClusterTests > Currently all of them execute without an option to choose which one to run. > To enable this we should make it configurable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-7174) Rebuild HBase in connectors github action CI script
[ https://issues.apache.org/jira/browse/PHOENIX-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-7174: - Description: I see test failures which I suspect are because the tests are using HBase 2.4 built for Hadoop 2. Add a step to rebuild HBase in the github actions script. was: I see test failures which I suspect are because the tests are using HBase 2.4 build for Hadoop 2. Add a step to rebuild HBase in the github actions script. > Rebuild HBase in connectors github action CI script > --- > > Key: PHOENIX-7174 > URL: https://issues.apache.org/jira/browse/PHOENIX-7174 > Project: Phoenix > Issue Type: Bug > Components: connectors >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Labels: test > Fix For: connectors-6.0.0 > > > I see test failures which I suspect are because the tests are using HBase 2.4 > built for Hadoop 2. > Add a step to rebuild HBase in the github actions script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-7156) Run integration tests based on @Category
[ https://issues.apache.org/jira/browse/PHOENIX-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajeshbabu Chintaguntla updated PHOENIX-7156: - Fix Version/s: 5.1.4 > Run integration tests based on @Category > > > Key: PHOENIX-7156 > URL: https://issues.apache.org/jira/browse/PHOENIX-7156 > Project: Phoenix > Issue Type: Improvement >Reporter: Nikita Pande >Priority: Major > Fix For: 5.2.0, 5.1.4 > > > Following are the categories described in integration tests of phoenix. > * ParallelStatsEnabledTests > * ParallelStatsDisabledTests > * NeedTheirOwnClusterTests > Currently all of them execute without an option to choose which one to run. > To enable this we should make it configurable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-7156) Run integration tests based on @Category
[ https://issues.apache.org/jira/browse/PHOENIX-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajeshbabu Chintaguntla updated PHOENIX-7156: - Fix Version/s: 5.2.0 > Run integration tests based on @Category > > > Key: PHOENIX-7156 > URL: https://issues.apache.org/jira/browse/PHOENIX-7156 > Project: Phoenix > Issue Type: Improvement >Reporter: Nikita Pande >Priority: Major > Fix For: 5.2.0 > > > Following are the categories described in integration tests of phoenix. > * ParallelStatsEnabledTests > * ParallelStatsDisabledTests > * NeedTheirOwnClusterTests > Currently all of them execute without an option to choose which one to run. > To enable this we should make it configurable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[VOTE] Release of Apache Phoenix Omid 1.1.1 RC0
Please vote on this Apache phoenix omid release candidate, phoenix-omid-1.1.1RC0 The VOTE will remain open for at least 72 hours. [ ] +1 Release this package as Apache phoenix omid 1.1.1 [ ] -1 Do not release this package because ... The tag to be voted on is 1.1.1RC0: https://github.com/apache/phoenix-omid/tree/1.1.1RC0 The release files, including signatures, digests, as well as CHANGES.md and RELEASENOTES.md included in this RC can be found at: https://dist.apache.org/repos/dist/dev/phoenix/phoenix-omid-1.1.1RC0/ Maven artifacts are available in a staging repository at: https://repository.apache.org/content/repositories/orgapachephoenix-1251/ Artifacts were signed with the 0x2CC0FD99 key which can be found in: https://dist.apache.org/repos/dist/release/phoenix/KEYS To learn more about Apache phoenix omid, please see https://phoenix.apache.org/ Thanks, Rajeshbabu.
[jira] [Assigned] (PHOENIX-7172) Support HBase 2.6
[ https://issues.apache.org/jira/browse/PHOENIX-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richárd Antal reassigned PHOENIX-7172: -- Assignee: Richárd Antal > Support HBase 2.6 > - > > Key: PHOENIX-7172 > URL: https://issues.apache.org/jira/browse/PHOENIX-7172 > Project: Phoenix > Issue Type: Improvement > Components: core >Affects Versions: 5.2.0, 5.1.3 >Reporter: Istvan Toth >Assignee: Richárd Antal >Priority: Major > > HBase 2.6.0 release work is ongoing. > Make sure Phoenix works with it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-7170) Conditional TTL
[ https://issues.apache.org/jira/browse/PHOENIX-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir Ozdemir updated PHOENIX-7170: --- Description: Deleting rows using delete markers require running delete queries to insert them, one for each row to be deleted. Often applications need to run periodic jobs to issue delete queries to insert delete markers. Deleting rows using TTL is more performance optimized compared to adding delete markers in Phoenix since TTL works without inserting delete markers. Phoenix currently supports table and view (level) TTL. It is desirable to have a conditional TTL feature to extend the TTL future to expire a subset of rows of a table or updatable view using a different TTL value. A condition TTL can be set using a CASE statement in CREATE and ALTER statements by adding TTL=. For example, TTL = CASE WHEN ID IS BETWEEN 1 AND 100 THEN <10 days> WHEN ID IS BETWEEN 101 AND 200 <7 days> ELSE <5 days> END The compaction scanner (CompactionScanner) in Phoenix can evaluate the case statement on a row and decide if the row should be removed. Similarly, on the read path TTLRegionScanner can mask the rows using the case statement. The TTL case statement can be stored in SYSCAT in header rows. was: Deleting rows using delete markers require running delete queries to insert them, one for each row to be deleted. Often applications need to run periodic jobs to issue delete queries to insert delete markers. Deleting rows using TTL is more performance optimized compared to adding delete markers in Phoenix since TTL works without inserting delete markers. Phoenix currently supports table and view (level) TTL. It is desirable to have a conditional TTL feature to extend the TTL future to expire a subset of rows of a table or updatable view using a different TTL value than the rest of the rows. A condition TTL can be set using a CASE statement in CREATE and ALTER statements by adding TTL=. For example, TTL = CASE WHEN ID IS BETWEEN 1 AND 100 THEN <10 days> WHEN ID IS BETWEEN 101 AND 200 <7 days> ELSE <5 days> END The compaction scanner (CompactionScanner) in Phoenix can evaluate the case statement on a row and decide if the row should be removed. Similarly, on the read path TTLRegionScanner can mask the rows using the case statement. The TTL case statement can be stored in SYSCAT in header rows. > Conditional TTL > --- > > Key: PHOENIX-7170 > URL: https://issues.apache.org/jira/browse/PHOENIX-7170 > Project: Phoenix > Issue Type: New Feature >Reporter: Kadir Ozdemir >Priority: Major > > Deleting rows using delete markers require running delete queries to insert > them, one for each row to be deleted. Often applications need to run periodic > jobs to issue delete queries to insert delete markers. Deleting rows using > TTL is more performance optimized compared to adding delete markers in > Phoenix since TTL works without inserting delete markers. Phoenix currently > supports table and view (level) TTL. It is desirable to have a conditional > TTL feature to extend the TTL future to expire a subset of rows of a table or > updatable view using a different TTL value. > A condition TTL can be set using a CASE statement in CREATE and ALTER > statements by adding TTL=. For example, > TTL = CASE WHEN ID IS BETWEEN 1 AND 100 THEN <10 days> WHEN ID IS BETWEEN 101 > AND 200 <7 days> ELSE <5 days> END > The compaction scanner (CompactionScanner) in Phoenix can evaluate the case > statement on a row and decide if the row should be removed. Similarly, on the > read path TTLRegionScanner can mask the rows using the case statement. The > TTL case statement can be stored in SYSCAT in header rows. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-7152) SchemaExtractionProcessor package does not match directory
[ https://issues.apache.org/jira/browse/PHOENIX-7152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-7152: - Description: This doesn't break maven compilation, but it does break Eclipse. (was: This doesn't break maven compilation, but it doesn break Eclipse.) > SchemaExtractionProcessor package does not match directory > -- > > Key: PHOENIX-7152 > URL: https://issues.apache.org/jira/browse/PHOENIX-7152 > Project: Phoenix > Issue Type: Bug >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Fix For: 5.2.0 > > > This doesn't break maven compilation, but it does break Eclipse. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-7174) Rebuild HBase in connectors github action CI script
[ https://issues.apache.org/jira/browse/PHOENIX-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-7174: - Labels: test (was: ) > Rebuild HBase in connectors github action CI script > --- > > Key: PHOENIX-7174 > URL: https://issues.apache.org/jira/browse/PHOENIX-7174 > Project: Phoenix > Issue Type: Bug > Components: connectors >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Labels: test > > I see test failures which I suspect are because the tests are using HBase 2.4 > build for Hadoop 2. > Add a step to rebuild HBase in the github actions script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-7170) Conditional TTL
[ https://issues.apache.org/jira/browse/PHOENIX-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir Ozdemir updated PHOENIX-7170: --- Description: Deleting rows using delete markers require running delete queries to insert them, one for each row to be deleted. Often applications need to run periodic jobs to issue delete queries to insert delete markers. Deleting rows using TTL is more performance optimized compared to adding delete markers in Phoenix since TTL works without inserting delete markers. Phoenix currently supports table and view (level) TTL. It is desirable to have a conditional TTL feature to extend the TTL future to expire a subset of rows of a table or updatable view using a different TTL value than the rest of the rows. A condition TTL can be set using a CASE statement in CREATE and ALTER statements by adding TTL=. For example, TTL = CASE WHEN ID IS BETWEEN 1 AND 100 THEN <10 days> WHEN ID IS BETWEEN 101 AND 200 <7 days> ELSE <5 days> END The compaction scanner (CompactionScanner) in Phoenix can evaluate the case statement on a row and decide if the row should be removed. Similarly, on the read path TTLRegionScanner can mask the rows using the case statement. The TTL case statement can be stored in SYSCAT in header rows. was: Deleting rows using delete markers require running delete queries to insert them, one for each row to be deleted. Often applications need to run periodic jobs to issue delete queries to insert delete markers. Deleting rows using TTL is more performance optimized compared to adding delete markers in Phoenix since TTL works without inserting delete markers. Phoenix currently supports table and view (level) TTL. It is desirable to have a row level TTL feature to extend the TTL future to delete a subset of rows of a table or updatable view. A row-level-TTL can be set using a CASE statement in CREATE and ALTER statements by adding TTL=. For example, TTL = CASE WHEN ID IS BETWEEN 1 AND 100 THEN <10 days> WHEN ID IS BETWEEN 101 AND 200 <7 days> ELSE <5 days> END The compaction scanner (CompactionScanner) in Phoenix can evaluate the case statement on a row and decide if the row should be deleted. Similarly, on the read path TTLRegionScanner can mask the deleted rows using the case statement. The TTL case statement can be stored in SYSCAT in header rows. > Conditional TTL > --- > > Key: PHOENIX-7170 > URL: https://issues.apache.org/jira/browse/PHOENIX-7170 > Project: Phoenix > Issue Type: New Feature >Reporter: Kadir Ozdemir >Priority: Major > > Deleting rows using delete markers require running delete queries to insert > them, one for each row to be deleted. Often applications need to run periodic > jobs to issue delete queries to insert delete markers. Deleting rows using > TTL is more performance optimized compared to adding delete markers in > Phoenix since TTL works without inserting delete markers. Phoenix currently > supports table and view (level) TTL. It is desirable to have a conditional > TTL feature to extend the TTL future to expire a subset of rows of a table or > updatable view using a different TTL value than the rest of the rows. > A condition TTL can be set using a CASE statement in CREATE and ALTER > statements by adding TTL=. For example, > TTL = CASE WHEN ID IS BETWEEN 1 AND 100 THEN <10 days> WHEN ID IS BETWEEN 101 > AND 200 <7 days> ELSE <5 days> END > The compaction scanner (CompactionScanner) in Phoenix can evaluate the case > statement on a row and decide if the row should be removed. Similarly, on the > read path TTLRegionScanner can mask the rows using the case statement. The > TTL case statement can be stored in SYSCAT in header rows. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-7170) Conditional TTL
[ https://issues.apache.org/jira/browse/PHOENIX-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir Ozdemir updated PHOENIX-7170: --- Summary: Conditional TTL (was: Phoenix Row TTL) > Conditional TTL > --- > > Key: PHOENIX-7170 > URL: https://issues.apache.org/jira/browse/PHOENIX-7170 > Project: Phoenix > Issue Type: New Feature >Reporter: Kadir Ozdemir >Priority: Major > > Deleting rows using delete markers require running delete queries to insert > them, one for each row to be deleted. Often applications need to run periodic > jobs to issue delete queries to insert delete markers. Deleting rows using > TTL is more performance optimized compared to adding delete markers in > Phoenix since TTL works without inserting delete markers. Phoenix currently > supports table and view (level) TTL. It is desirable to have a row level TTL > feature to extend the TTL future to delete a subset of rows of a table or > updatable view. > A row-level-TTL can be set using a CASE statement in CREATE and ALTER > statements by adding TTL=. For example, > TTL = CASE WHEN ID IS BETWEEN 1 AND 100 THEN <10 days> WHEN ID IS BETWEEN 101 > AND 200 <7 days> ELSE <5 days> END > The compaction scanner (CompactionScanner) in Phoenix can evaluate the case > statement on a row and decide if the row should be deleted. Similarly, on the > read path TTLRegionScanner can mask the deleted rows using the case > statement. The TTL case statement can be stored in SYSCAT in header rows. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (PHOENIX-7174) Rebuild HBase in connectors github action CI script
Istvan Toth created PHOENIX-7174: Summary: Rebuild HBase in connectors github action CI script Key: PHOENIX-7174 URL: https://issues.apache.org/jira/browse/PHOENIX-7174 Project: Phoenix Issue Type: Bug Components: connectors Reporter: Istvan Toth I see test failures which I suspect are because the tests are using HBase 2.4 build for Hadoop 2. Add a step to rebuild HBase in the github actions script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (PHOENIX-7174) Rebuild HBase in connectors github action CI script
[ https://issues.apache.org/jira/browse/PHOENIX-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth reassigned PHOENIX-7174: Assignee: Istvan Toth > Rebuild HBase in connectors github action CI script > --- > > Key: PHOENIX-7174 > URL: https://issues.apache.org/jira/browse/PHOENIX-7174 > Project: Phoenix > Issue Type: Bug > Components: connectors >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > > I see test failures which I suspect are because the tests are using HBase 2.4 > build for Hadoop 2. > Add a step to rebuild HBase in the github actions script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-7173) Update default HBase versions to 2.4.17 and 2.5.7 respectively
[ https://issues.apache.org/jira/browse/PHOENIX-7173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-7173: - Issue Type: Task (was: Improvement) > Update default HBase versions to 2.4.17 and 2.5.7 respectively > -- > > Key: PHOENIX-7173 > URL: https://issues.apache.org/jira/browse/PHOENIX-7173 > Project: Phoenix > Issue Type: Task > Components: core >Affects Versions: 5.2.0, 5.1.4 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > > We haven't updated to the latest HBase releases for a while. 2.4.17 has been > out for 6+ months. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-7173) Update default HBase versions to 2.4.17 and 2.5.7 respectively
[ https://issues.apache.org/jira/browse/PHOENIX-7173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-7173: - Summary: Update default HBase versions to 2.4.17 and 2.5.7 respectively (was: Update HBase version to 2.4.17 and 2.5.7 respectively) > Update default HBase versions to 2.4.17 and 2.5.7 respectively > -- > > Key: PHOENIX-7173 > URL: https://issues.apache.org/jira/browse/PHOENIX-7173 > Project: Phoenix > Issue Type: Improvement > Components: core >Affects Versions: 5.2.0, 5.1.4 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > > We haven't updated to the latest HBase releases for a while. 2.4.17 has been > out for 6+ months. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (PHOENIX-7173) Update HBase version to 2.4.17 and 2.5.7 respectively
Istvan Toth created PHOENIX-7173: Summary: Update HBase version to 2.4.17 and 2.5.7 respectively Key: PHOENIX-7173 URL: https://issues.apache.org/jira/browse/PHOENIX-7173 Project: Phoenix Issue Type: Improvement Components: core Affects Versions: 5.2.0, 5.1.4 Reporter: Istvan Toth Assignee: Istvan Toth We haven't updated to the latest HBase releases for a while. 2.4.17 has been out for 6+ months. -- This message was sent by Atlassian Jira (v8.20.10#820010)
