[jira] [Closed] (PHOENIX-5736) Mutable global index rebuilds are incorrect after PHOENIX-5494

[Kadir OZDEMIR (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kadir OZDEMIR closed PHOENIX-5736.
--

> Mutable global index rebuilds are incorrect after PHOENIX-5494
> --
>
> Key: PHOENIX-5736
> URL: https://issues.apache.org/jira/browse/PHOENIX-5736
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 5.0.0
>Reporter: Kadir OZDEMIR
>Priority: Critical
> Attachments: skipScanTest.txt
>
>
> PHOENIX-5494 uses skip scans to improve write performance for tables with 
> indexes. Before this jira, a separate scanner was opened for each data table 
> mutation to read all versions and delete markers of for the row to be 
> mutated. With this jira, a single scanner is opened using a raw scan with a 
> skip scan filter to read all versions and delete markers of the all rows in a 
> batch. Reading existing data table rows is required to generate index updates.
> However, I have discovered that a raw scan with a skip scan filter does not 
> return all raw versions. This means that after PHOENIX-5494 index rebuilds 
> for global indexes will not be correct. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (PHOENIX-5736) Mutable global index rebuilds are incorrect after PHOENIX-5494

[Kadir OZDEMIR (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kadir OZDEMIR resolved PHOENIX-5736.

Resolution: Not A Problem

> Mutable global index rebuilds are incorrect after PHOENIX-5494
> --
>
> Key: PHOENIX-5736
> URL: https://issues.apache.org/jira/browse/PHOENIX-5736
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 5.0.0
>Reporter: Kadir OZDEMIR
>Priority: Critical
> Attachments: skipScanTest.txt
>
>
> PHOENIX-5494 uses skip scans to improve write performance for tables with 
> indexes. Before this jira, a separate scanner was opened for each data table 
> mutation to read all versions and delete markers of for the row to be 
> mutated. With this jira, a single scanner is opened using a raw scan with a 
> skip scan filter to read all versions and delete markers of the all rows in a 
> batch. Reading existing data table rows is required to generate index updates.
> However, I have discovered that a raw scan with a skip scan filter does not 
> return all raw versions. This means that after PHOENIX-5494 index rebuilds 
> for global indexes will not be correct. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

[Sandeep Guggilam (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: PHOENIX-5607.4.x-HBase-1.3.v3.patch

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v3.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

[Sandeep Guggilam (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: (was: PHOENIX-5607.4.x-HBase-1.3.v3.patch)

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v3.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

[Sandeep Guggilam (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: PHOENIX-5607.4.x-HBase-1.3.v3.patch

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v3.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

[Sandeep Guggilam (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: PHOENIX-5607.4.x-HBase-1.3.v3.patch

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v3.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

[Sandeep Guggilam (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: (was: PHOENIX-5607.4.x-HBase-1.3.v3.patch)

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

[Sandeep Guggilam (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: (was: PHOENIX-5607.4.x-HBase-1.3.v3.patch)

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v3.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

[Sandeep Guggilam (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: PHOENIX-5607.4.x-HBase-1.3.v3.patch

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v3.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

[Sandeep Guggilam (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: (was: PHOENIX-5607.4.x-HBase-1.3.v3.patch)

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v3.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (PHOENIX-5740) WhereOptmizer doesn't generate optimized query plan

[Xinyi Yan (Jira)]

Xinyi Yan created PHOENIX-5740:
--

 Summary: WhereOptmizer doesn't generate optimized query plan
 Key: PHOENIX-5740
 URL: https://issues.apache.org/jira/browse/PHOENIX-5740
 Project: Phoenix
  Issue Type: Improvement
Reporter: Xinyi Yan
 Attachments: Screen Shot 2020-02-19 at 4.41.12 PM.png

!Screen Shot 2020-02-19 at 4.41.12 PM.png!

AS we can see, the pattern of WHERE (( all pk conditions) OR ( all pk 
conditions)) generates the wrong scan.

Instead of a full scan, it should be a point lookup since we have full primary 
key listed. 

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5740) WhereOptmizer doesn't generate optimized query plan

[Xinyi Yan (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xinyi Yan updated PHOENIX-5740:
---
Description: 
!Screen Shot 2020-02-19 at 4.41.12 PM.png!
{code:java}
0: jdbc:phoenix:localhost:49454> CREATE TABLE FOO (ID1 BIGINT NOT NULL , ID2 
BIGINT NOT NULL, CONSTRAINT PK PRIMARY KEY(ID1, ID2));
No rows affected (1.262 seconds)
0: jdbc:phoenix:localhost:49454> EXPLAIN SELECT * FROM FOO WHERE ((ID1=1 AND 
ID2=1) OR (ID1=2 AND ID2=2));
+---+-++--+
|   PLAN
| EST_BYTES_READ  | EST_ROWS_READ  | EST_ |
+---+-++--+
| CLIENT 1-CHUNK PARALLEL 1-WAY ROUND ROBIN FULL SCAN OVER FOO  
| null| null   | null |
| SERVER FILTER BY FIRST KEY ONLY AND ((ID1 = 1 AND ID2 = 1) OR (ID1 = 2 
AND ID2 = 2))  | null| null   | null |
+---+-++--+
2 rows selected (0.008 seconds)
{code}
 

AS we can see, the pattern of WHERE (( all pk conditions) OR ( all pk 
conditions)) generates the wrong scan.

Instead of a full scan, it should be a point lookup since we have full primary 
key listed. 

 

 

  was:
!Screen Shot 2020-02-19 at 4.41.12 PM.png!

AS we can see, the pattern of WHERE (( all pk conditions) OR ( all pk 
conditions)) generates the wrong scan.

Instead of a full scan, it should be a point lookup since we have full primary 
key listed. 

 

 


> WhereOptmizer doesn't generate optimized query plan
> ---
>
> Key: PHOENIX-5740
> URL: https://issues.apache.org/jira/browse/PHOENIX-5740
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Xinyi Yan
>Priority: Major
> Attachments: Screen Shot 2020-02-19 at 4.41.12 PM.png
>
>
> !Screen Shot 2020-02-19 at 4.41.12 PM.png!
> {code:java}
> 0: jdbc:phoenix:localhost:49454> CREATE TABLE FOO (ID1 BIGINT NOT NULL , ID2 
> BIGINT NOT NULL, CONSTRAINT PK PRIMARY KEY(ID1, ID2));
> No rows affected (1.262 seconds)
> 0: jdbc:phoenix:localhost:49454> EXPLAIN SELECT * FROM FOO WHERE ((ID1=1 AND 
> ID2=1) OR (ID1=2 AND ID2=2));
> +---+-++--+
> |   PLAN  
>   | EST_BYTES_READ  | EST_ROWS_READ  | EST_ |
> +---+-++--+
> | CLIENT 1-CHUNK PARALLEL 1-WAY ROUND ROBIN FULL SCAN OVER FOO
>   | null| null   | null |
> | SERVER FILTER BY FIRST KEY ONLY AND ((ID1 = 1 AND ID2 = 1) OR (ID1 = 2 
> AND ID2 = 2))  | null| null   | null |
> +---+-++--+
> 2 rows selected (0.008 seconds)
> {code}
>  
> AS we can see, the pattern of WHERE (( all pk conditions) OR ( all pk 
> conditions)) generates the wrong scan.
> Instead of a full scan, it should be a point lookup since we have full 
> primary key listed. 
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

[Sandeep Guggilam (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: PHOENIX-5607.4.x-HBase-1.3.v3.patch

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v3.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

[Sandeep Guggilam (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: (was: PHOENIX-5607.4.x-HBase-1.3.v3.patch)

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v3.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5737) Hadoop QA run says no tests even though there are added IT tests

[Sandeep Guggilam (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5737:
--
Attachment: PHOENIX-5737.master.patch

> Hadoop QA run says no tests even though there are added IT tests
> 
>
> Key: PHOENIX-5737
> URL: https://issues.apache.org/jira/browse/PHOENIX-5737
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 5.0.0
>Reporter: Sandeep Guggilam
>Assignee: Sandeep Guggilam
>Priority: Minor
> Fix For: 5.1.0
>
> Attachments: PHOENIX-5737.master.patch
>
>
> Even though there are ITs added in the patch, Hadoop QA run complains about 
> not adding any new tests



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

[Sandeep Guggilam (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: PHOENIX-5607.4.x-HBase-1.3.v3.patch

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v3.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5636) Improve the error message when client connects to server with higher major version

[Christine Feng (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Feng updated PHOENIX-5636:

Attachment: PHOENIX-5636.master.v9.patch

> Improve the error message when client connects to server with higher major 
> version
> --
>
> Key: PHOENIX-5636
> URL: https://issues.apache.org/jira/browse/PHOENIX-5636
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Sandeep Guggilam
>Assignee: Christine Feng
>Priority: Minor
>  Labels: beginner, newbie
> Fix For: 4.15.1
>
> Attachments: PHOENIX-5636.master.v1.patch, 
> PHOENIX-5636.master.v2.patch, PHOENIX-5636.master.v3.patch, 
> PHOENIX-5636.master.v4.patch, PHOENIX-5636.master.v5.patch, 
> PHOENIX-5636.master.v6.patch, PHOENIX-5636.master.v7.patch, 
> PHOENIX-5636.master.v8.patch, PHOENIX-5636.master.v9.patch
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When a 4.14 client connects to a 5.0 server, it errors out saying " Outdated 
> jars. Newer Phoenix clients can't communicate with older Phoenix servers"
> It should probably error out with "Major version of client is less than that 
> of the server"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (PHOENIX-5735) IndexTool's inline verification should not verify rows beyond max lookback age

[Swaroopa Kadam (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Swaroopa Kadam reassigned PHOENIX-5735:
---

Assignee: Weiming Wang

> IndexTool's inline verification should not verify rows beyond max lookback age
> --
>
> Key: PHOENIX-5735
> URL: https://issues.apache.org/jira/browse/PHOENIX-5735
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Swaroopa Kadam
>Assignee: Weiming Wang
>Priority: Major
> Fix For: 5.1.0, 4.15.1
>
>
> IndexTool's inline verification should not verify rows beyond max lookback age
> Similar to Phoenix-5734



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Unifying the 4.x branches

[Andrew Purtell]

Since you have already done this great work, and 1.3 isn’t dead yet, and won’t 
be “this year”, and it serves as an example of how to bring in entire new 
features on later code lines, perhaps it should go in. Just my 0.02. 

> On Feb 19, 2020, at 10:39 AM, Istvan Toth  wrote:
> 
> Geoffrey,
> 
> Absolutely.
> 80% of this patch is dealing with 1.3.
> 1.4 vs 1.5 affects two or three java files.
> 
> My game plan is to submit two different patches, a small one for 1.4 and
> 1.5 support, and a bigger one other that adds 1.3, so that it can be
> reverted easily after 1.3 is dropped.
> 
> I think that maintaining a separate 1.3 branch is the least desirable
> outcome, as we'd still have two 4.x branches to maintain, with different
> jenkins jobs, and slightly different jar names and maven artifact structure.
> 
> Of course the easiest route is to just drop 1.3 support ASAP, and then
> unify 1.4 and 1.5 .
> 
> If we are not ready to drop 1.3 very soon, I'd vote for unifying with
> 1.3 included (I've finished the hard part), and then reverting a lot of
> the compatibility cruft when we drop 1.3 support.
> 
> As for the 4.15 maintenance releases, those could stay on the current
> branches, as we probably want point releases to be drop-in compatible,
> and the unified version changes the maven artifact versioning, and some
> jar filenames. This would be one way to extend some support for 1.3
> 
> regards
> István
> 
> 
> 
>> On 2020. 02. 19. 19:11, Geoffrey Jacoby wrote:
>> Istvan,
>> 
>> The HBase community has been on the verge of EOLing 1.3 for some time
>> now -- are there significant gains or simplification if we either end
>> 1.3 support in Phoenix before PHOENIX-5721 goes in, or alternately,
>> don't include it in the unified profile since it will be EOLed in the
>> not-too-distant-future even if we don't do it now? 
>> 
>> Geoffrey
>> 
>> On Wed, Feb 19, 2020 at 5:36 AM Istvan Toth > > wrote:
>> 
>>Now I have an unpolished version of the unified 4.x branch at
>>https://github.com/stoty/phoenix/tree/PHOENIX-5721
>> 
>>It takes the same approach as the  master branch, though there are a bit
>>more differences to hide in the versions.
>> 
>>I need to finish the assembly stuff, go over once more the changes,
>>and run
>>full ITs on each profile, but I expect that
>>the Java code will mostly see whitespace changes, so you can check the
>>logic behind the changes.
>> 
>>The HBase metrics stuff in particular is interesting, because the whole
>>feature is missing from 1.3, so it can be used as an example on how
>>we can
>>adopt new HBase features later.
>> 
>>On Mon, Feb 10, 2020 at 9:01 AM Istvan Toth >> wrote:
>> 
>>> Created PHOENIX-5721
>> to
>>> track this.
>>> 
>>> On Mon, Feb 10, 2020 at 8:21 AM István Tóth >> wrote:
>>> 
 Thanks for the feedback, Geoffrey.
 
 I took the lazy option of just creating compatibility methods to
>>paper
 over the HBase API changes (emulate the latest version) when we
>>are calling
 into HBase.
 
 For the APIs implemented by Phoenix, I added compatibility
>>superclasses.
 So I expect that we will be able to add a dummy
>>RegionObserver.preWALAppend
 to the compatibility coprocessor superclass(es), so that the same
>>code
 compiles for older versions as well.
 
 Of course if other code paths depend on having that
>>functionality, those
 should also be gated by similar compatibility shims/version checks.
 
 My current approach is a quick fix, and does not preclude (in fact it
 enables) later efforts at refactoring/cleanup.
 
 On Fri, Feb 7, 2020 at 7:31 PM Geoffrey Jacoby
>>mailto:gjac...@apache.org>>
 wrote:
 
> If unification could be done, that would be great. (I apologize
>>that I
> haven't had the bandwidth over the past week or two to take a
>>close look
> at
> the work Istvan has been doing to unify the 5.x branches -- as
>>one who
> spends too much time cherry-picking I very much appreciate this
>>effort!
> :-)
> )
> 
> I still think the hardest part, as I think I mentioned in some
>>previous
> thread, is what to do when the HBase coprocs themselves diverge
>>between
> minor versions, as they can do. How do you handle the fact that
> RegionObserver.preWALAppend exists in 1.5 but not 1.3 and 1.4,
>>and will
> exist in 2.3 but not 2.2 and 2.1? And that therefore any
>>features that
> depend on preWALAppend existing (none yet, but they're coming
>>later this
> year) will work in a 1.5 or 2.3 environment, but not a 1.4 or
>>2.2 one?
> 
> Since our coprocessors tend to be giant monoliths, trying to create
> release-based versions of them selectable by maven profile 

Re: [DISCUSS] Unifying the 4.x branches

[Istvan Toth]

Geoffrey,

Absolutely.
80% of this patch is dealing with 1.3.
1.4 vs 1.5 affects two or three java files.

My game plan is to submit two different patches, a small one for 1.4 and
1.5 support, and a bigger one other that adds 1.3, so that it can be
reverted easily after 1.3 is dropped.

I think that maintaining a separate 1.3 branch is the least desirable
outcome, as we'd still have two 4.x branches to maintain, with different
jenkins jobs, and slightly different jar names and maven artifact structure.

Of course the easiest route is to just drop 1.3 support ASAP, and then
unify 1.4 and 1.5 .

If we are not ready to drop 1.3 very soon, I'd vote for unifying with
1.3 included (I've finished the hard part), and then reverting a lot of
the compatibility cruft when we drop 1.3 support.

As for the 4.15 maintenance releases, those could stay on the current
branches, as we probably want point releases to be drop-in compatible,
and the unified version changes the maven artifact versioning, and some
jar filenames. This would be one way to extend some support for 1.3

regards
István



On 2020. 02. 19. 19:11, Geoffrey Jacoby wrote:
> Istvan,
> 
> The HBase community has been on the verge of EOLing 1.3 for some time
> now -- are there significant gains or simplification if we either end
> 1.3 support in Phoenix before PHOENIX-5721 goes in, or alternately,
> don't include it in the unified profile since it will be EOLed in the
> not-too-distant-future even if we don't do it now? 
> 
> Geoffrey
> 
> On Wed, Feb 19, 2020 at 5:36 AM Istvan Toth  > wrote:
> 
> Now I have an unpolished version of the unified 4.x branch at
> https://github.com/stoty/phoenix/tree/PHOENIX-5721
> 
> It takes the same approach as the  master branch, though there are a bit
> more differences to hide in the versions.
> 
> I need to finish the assembly stuff, go over once more the changes,
> and run
> full ITs on each profile, but I expect that
> the Java code will mostly see whitespace changes, so you can check the
> logic behind the changes.
> 
> The HBase metrics stuff in particular is interesting, because the whole
> feature is missing from 1.3, so it can be used as an example on how
> we can
> adopt new HBase features later.
> 
> On Mon, Feb 10, 2020 at 9:01 AM Istvan Toth  > wrote:
> 
> > Created PHOENIX-5721
>  to
> > track this.
> >
> > On Mon, Feb 10, 2020 at 8:21 AM István Tóth  > wrote:
> >
> >> Thanks for the feedback, Geoffrey.
> >>
> >> I took the lazy option of just creating compatibility methods to
> paper
> >> over the HBase API changes (emulate the latest version) when we
> are calling
> >> into HBase.
> >>
> >> For the APIs implemented by Phoenix, I added compatibility
> superclasses.
> >> So I expect that we will be able to add a dummy
> RegionObserver.preWALAppend
> >> to the compatibility coprocessor superclass(es), so that the same
> code
> >> compiles for older versions as well.
> >>
> >> Of course if other code paths depend on having that
> functionality, those
> >> should also be gated by similar compatibility shims/version checks.
> >>
> >> My current approach is a quick fix, and does not preclude (in fact it
> >> enables) later efforts at refactoring/cleanup.
> >>
> >> On Fri, Feb 7, 2020 at 7:31 PM Geoffrey Jacoby
> mailto:gjac...@apache.org>>
> >> wrote:
> >>
> >>> If unification could be done, that would be great. (I apologize
> that I
> >>> haven't had the bandwidth over the past week or two to take a
> close look
> >>> at
> >>> the work Istvan has been doing to unify the 5.x branches -- as
> one who
> >>> spends too much time cherry-picking I very much appreciate this
> effort!
> >>> :-)
> >>> )
> >>>
> >>> I still think the hardest part, as I think I mentioned in some
> previous
> >>> thread, is what to do when the HBase coprocs themselves diverge
> between
> >>> minor versions, as they can do. How do you handle the fact that
> >>> RegionObserver.preWALAppend exists in 1.5 but not 1.3 and 1.4,
> and will
> >>> exist in 2.3 but not 2.2 and 2.1? And that therefore any
> features that
> >>> depend on preWALAppend existing (none yet, but they're coming
> later this
> >>> year) will work in a 1.5 or 2.3 environment, but not a 1.4 or
> 2.2 one?
> >>>
> >>> Since our coprocessors tend to be giant monoliths, trying to create
> >>> release-based versions of them selectable by maven profile would
> >>> either require lots of developer copy/paste for each change, or a
> >>> significant (probably long overdue) refactor to make the coprocs
> small
> >>> shims that call out to 

Re: [DISCUSS] Unifying the 4.x branches

[Geoffrey Jacoby]

Istvan,

The HBase community has been on the verge of EOLing 1.3 for some time now
-- are there significant gains or simplification if we either end 1.3
support in Phoenix before PHOENIX-5721 goes in, or alternately, don't
include it in the unified profile since it will be EOLed in the
not-too-distant-future even if we don't do it now?

Geoffrey

On Wed, Feb 19, 2020 at 5:36 AM Istvan Toth  wrote:

> Now I have an unpolished version of the unified 4.x branch at
> https://github.com/stoty/phoenix/tree/PHOENIX-5721
>
> It takes the same approach as the  master branch, though there are a bit
> more differences to hide in the versions.
>
> I need to finish the assembly stuff, go over once more the changes, and run
> full ITs on each profile, but I expect that
> the Java code will mostly see whitespace changes, so you can check the
> logic behind the changes.
>
> The HBase metrics stuff in particular is interesting, because the whole
> feature is missing from 1.3, so it can be used as an example on how we can
> adopt new HBase features later.
>
> On Mon, Feb 10, 2020 at 9:01 AM Istvan Toth  wrote:
>
> > Created PHOENIX-5721 
> to
> > track this.
> >
> > On Mon, Feb 10, 2020 at 8:21 AM István Tóth  wrote:
> >
> >> Thanks for the feedback, Geoffrey.
> >>
> >> I took the lazy option of just creating compatibility methods to paper
> >> over the HBase API changes (emulate the latest version) when we are
> calling
> >> into HBase.
> >>
> >> For the APIs implemented by Phoenix, I added compatibility superclasses.
> >> So I expect that we will be able to add a dummy
> RegionObserver.preWALAppend
> >> to the compatibility coprocessor superclass(es), so that the same code
> >> compiles for older versions as well.
> >>
> >> Of course if other code paths depend on having that functionality, those
> >> should also be gated by similar compatibility shims/version checks.
> >>
> >> My current approach is a quick fix, and does not preclude (in fact it
> >> enables) later efforts at refactoring/cleanup.
> >>
> >> On Fri, Feb 7, 2020 at 7:31 PM Geoffrey Jacoby 
> >> wrote:
> >>
> >>> If unification could be done, that would be great. (I apologize that I
> >>> haven't had the bandwidth over the past week or two to take a close
> look
> >>> at
> >>> the work Istvan has been doing to unify the 5.x branches -- as one who
> >>> spends too much time cherry-picking I very much appreciate this effort!
> >>> :-)
> >>> )
> >>>
> >>> I still think the hardest part, as I think I mentioned in some previous
> >>> thread, is what to do when the HBase coprocs themselves diverge between
> >>> minor versions, as they can do. How do you handle the fact that
> >>> RegionObserver.preWALAppend exists in 1.5 but not 1.3 and 1.4, and will
> >>> exist in 2.3 but not 2.2 and 2.1? And that therefore any features that
> >>> depend on preWALAppend existing (none yet, but they're coming later
> this
> >>> year) will work in a 1.5 or 2.3 environment, but not a 1.4 or 2.2 one?
> >>>
> >>> Since our coprocessors tend to be giant monoliths, trying to create
> >>> release-based versions of them selectable by maven profile would
> >>> either require lots of developer copy/paste for each change, or a
> >>> significant (probably long overdue) refactor to make the coprocs small
> >>> shims that call out to smaller, fine-grained classes that can
> >>> occasionally
> >>> be release-specific.
> >>>
> >>> Geoffrey
> >>>
> >>> On Fri, Feb 7, 2020 at 9:31 AM Josh Elser  wrote:
> >>>
> >>> > Sounds like a good idea to me.
> >>> >
> >>> > On 2/6/20 8:40 AM, Istvan Toth wrote:
> >>> > > Hello!
> >>> > >
> >>> > > Now that we have a working solution in master for handling
> different
> >>> > HBase
> >>> > > minor versions, I think that we should think about applying the
> same
> >>> > > template to 4.x., and unifying the 4.x-HBase-1.3, 1.4, and 1.5
> >>> branches.
> >>> > >
> >>> > > Are there any intentional differences between the branches, apart
> >>> from
> >>> > > having to conform to the slightly different APIs ?
> >>> > > If there are, what are they, and are they considered blockers?
> >>> > >
> >>> > > Any other reasons not do this ?
> >>> > >
> >>> > > I expect that based on my experience with the master branch, I can
> do
> >>> > this
> >>> > > in a few days, but I don't want to put in the effort if there is no
> >>> > > interest in it.
> >>> > >
> >>> > > My plan is to take the 1.5 branch as a base.
> >>> > >
> >>> > > best regards
> >>> > > Istvan
> >>> > >
> >>> >
> >>>
> >>
> >>
> >> --
> >> *István Tóth* | Sr. Software Engineer
> >> t. (36) 70 283-1788
> >> st...@cloudera.com 
> >> [image: Cloudera] 
> >> [image: Cloudera on Twitter]  [image:
> >> Cloudera on Facebook]  [image:
> >> Cloudera on LinkedIn] 
> >> 
> >> 

[jira] [Created] (PHOENIX-5739) Assembly is missing client jars

[Istvan Toth (Jira)]

Istvan Toth created PHOENIX-5739:


 Summary: Assembly is missing client jars
 Key: PHOENIX-5739
 URL: https://issues.apache.org/jira/browse/PHOENIX-5739
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 5.1.0
Reporter: Istvan Toth
Assignee: Istvan Toth


While adding HBase 2.x support, I missed a change in the filters that add the 
shaded fat client jars to the assembly.

As a result, the assembly is useless now.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Unifying the 4.x branches

[Istvan Toth]

Now I have an unpolished version of the unified 4.x branch at
https://github.com/stoty/phoenix/tree/PHOENIX-5721

It takes the same approach as the  master branch, though there are a bit
more differences to hide in the versions.

I need to finish the assembly stuff, go over once more the changes, and run
full ITs on each profile, but I expect that
the Java code will mostly see whitespace changes, so you can check the
logic behind the changes.

The HBase metrics stuff in particular is interesting, because the whole
feature is missing from 1.3, so it can be used as an example on how we can
adopt new HBase features later.

On Mon, Feb 10, 2020 at 9:01 AM Istvan Toth  wrote:

> Created PHOENIX-5721  to
> track this.
>
> On Mon, Feb 10, 2020 at 8:21 AM István Tóth  wrote:
>
>> Thanks for the feedback, Geoffrey.
>>
>> I took the lazy option of just creating compatibility methods to paper
>> over the HBase API changes (emulate the latest version) when we are calling
>> into HBase.
>>
>> For the APIs implemented by Phoenix, I added compatibility superclasses.
>> So I expect that we will be able to add a dummy RegionObserver.preWALAppend
>> to the compatibility coprocessor superclass(es), so that the same code
>> compiles for older versions as well.
>>
>> Of course if other code paths depend on having that functionality, those
>> should also be gated by similar compatibility shims/version checks.
>>
>> My current approach is a quick fix, and does not preclude (in fact it
>> enables) later efforts at refactoring/cleanup.
>>
>> On Fri, Feb 7, 2020 at 7:31 PM Geoffrey Jacoby 
>> wrote:
>>
>>> If unification could be done, that would be great. (I apologize that I
>>> haven't had the bandwidth over the past week or two to take a close look
>>> at
>>> the work Istvan has been doing to unify the 5.x branches -- as one who
>>> spends too much time cherry-picking I very much appreciate this effort!
>>> :-)
>>> )
>>>
>>> I still think the hardest part, as I think I mentioned in some previous
>>> thread, is what to do when the HBase coprocs themselves diverge between
>>> minor versions, as they can do. How do you handle the fact that
>>> RegionObserver.preWALAppend exists in 1.5 but not 1.3 and 1.4, and will
>>> exist in 2.3 but not 2.2 and 2.1? And that therefore any features that
>>> depend on preWALAppend existing (none yet, but they're coming later this
>>> year) will work in a 1.5 or 2.3 environment, but not a 1.4 or 2.2 one?
>>>
>>> Since our coprocessors tend to be giant monoliths, trying to create
>>> release-based versions of them selectable by maven profile would
>>> either require lots of developer copy/paste for each change, or a
>>> significant (probably long overdue) refactor to make the coprocs small
>>> shims that call out to smaller, fine-grained classes that can
>>> occasionally
>>> be release-specific.
>>>
>>> Geoffrey
>>>
>>> On Fri, Feb 7, 2020 at 9:31 AM Josh Elser  wrote:
>>>
>>> > Sounds like a good idea to me.
>>> >
>>> > On 2/6/20 8:40 AM, Istvan Toth wrote:
>>> > > Hello!
>>> > >
>>> > > Now that we have a working solution in master for handling different
>>> > HBase
>>> > > minor versions, I think that we should think about applying the same
>>> > > template to 4.x., and unifying the 4.x-HBase-1.3, 1.4, and 1.5
>>> branches.
>>> > >
>>> > > Are there any intentional differences between the branches, apart
>>> from
>>> > > having to conform to the slightly different APIs ?
>>> > > If there are, what are they, and are they considered blockers?
>>> > >
>>> > > Any other reasons not do this ?
>>> > >
>>> > > I expect that based on my experience with the master branch, I can do
>>> > this
>>> > > in a few days, but I don't want to put in the effort if there is no
>>> > > interest in it.
>>> > >
>>> > > My plan is to take the 1.5 branch as a base.
>>> > >
>>> > > best regards
>>> > > Istvan
>>> > >
>>> >
>>>
>>
>>
>> --
>> *István Tóth* | Sr. Software Engineer
>> t. (36) 70 283-1788
>> st...@cloudera.com 
>> [image: Cloudera] 
>> [image: Cloudera on Twitter]  [image:
>> Cloudera on Facebook]  [image:
>> Cloudera on LinkedIn] 
>> 
>> --
>>
>

[jira] [Updated] (PHOENIX-5709) Simplify index update generation code for consistent global indexes

[Kadir OZDEMIR (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kadir OZDEMIR updated PHOENIX-5709:
---
Attachment: PHOENIX-5709.4.x-HBase-1.3.006.patch

> Simplify index update generation code for consistent global indexes
> ---
>
> Key: PHOENIX-5709
> URL: https://issues.apache.org/jira/browse/PHOENIX-5709
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.14.3
>Reporter: Kadir OZDEMIR
>Assignee: Kadir OZDEMIR
>Priority: Major
> Fix For: 5.0.0, 4.14.3
>
> Attachments: PHOENIX-5709.4.x-HBase-1.3.001.patch, 
> PHOENIX-5709.4.x-HBase-1.3.002.patch, PHOENIX-5709.4.x-HBase-1.3.003.patch, 
> PHOENIX-5709.4.x-HBase-1.3.004.patch, PHOENIX-5709.4.x-HBase-1.3.005.patch, 
> PHOENIX-5709.4.x-HBase-1.3.006.patch, PHOENIX-5709.master.001.patch, 
> PHOENIX-5709.master.002.patch, PHOENIX-5709.master.003.patch, 
> PHOENIX-5709.master.004.patch, PHOENIX-5709.master.005.patch, 
> PHOENIX-5709.master.006.patch, PHOENIX-5709.master.007.patch, 
> PHOENIX-5709.master.008.patch, PHOENIX-5709.master.009.patch, 
> PHOENIX-5709.master.010.patch, PHOENIX-5709.master.011.patch, 
> PHOENIX-5709.master.012.patch, PHOENIX-5709.master.013.patch
>
>  Time Spent: 8h 20m
>  Remaining Estimate: 0h
>
> The implementation of the new global index design by PHOENIX-5156 essentially 
> introduced two coprocessors, IndexRegionObserver and GlobalIndexChecker. 
> IndexRegionObserver is the counterpart of the existing Indexer coprocessor 
> that the previous global indexing feature uses. It implements the indexing 
> write path. GlobalIndexChecker implements the read verification and read 
> repair that happens on the read path. One of the main objectives of the 
> design behind new global indexing was to leverage as much existing indexing 
> code as possible. This objective has been achieved greatly as the entire 
> index table update generation code implemented by various classes (including 
> PhoenixIndexBuilder, CachedLocalTable, NonTxIndexBuilder, IndexUpdateManager, 
>  LocalTableState, ScannerBuilder, IndexMemStore and PhoenixIndexCodec) is 
> leveraged as it is mainly. This objective has served us well to deliver the 
> new indexing feature quickly. The leveraged code is very complex, over 
> engineered, and inefficient, and is not bug free. It is very hard to 
> maintain. It is time to replace the complex set of classes with something 
> drastically simpler and more efficient for the new design.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)