phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-5188) IndexedKeyValue should populate KeyValue fields
Date Tue, 12 Mar 2019 22:56:00 GMT


Hadoop QA commented on PHOENIX-5188:

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment
  against master branch at commit f969444c96a060a5619e70e543c6d6fb21b32bed.
  ATTACHMENT ID: 12962175

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:green}+1 tests included{color}.  The patch appears to include 3 new or modified

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of
javac compiler warnings.

    {color:red}-1 release audit{color}.  The applied patch generated 1 release audit warnings
(more than the master's current 0 warnings).

    {color:green}+1 lineLengths{color}.  The patch does not introduce lines longer than 100

     {color:red}-1 core tests{color}.  The patch failed these unit tests:

Test results:
Release audit warnings:
Console output:

This message is automatically generated.

> IndexedKeyValue should populate KeyValue fields
> -----------------------------------------------
>                 Key: PHOENIX-5188
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 5.0.0, 4.14.1
>            Reporter: Geoffrey Jacoby
>            Assignee: Geoffrey Jacoby
>            Priority: Major
>         Attachments: PHOENIX-5188.patch
> IndexedKeyValue subclasses the HBase KeyValue class, which has three primary fields:
bytes, offset, and length. These fields aren't populated by IndexedKeyValue because it's concerned
with index mutations, and has its own fields that its own methods use. 
> However, KeyValue and its Cell interface have quite a few methods that assume these fields
are populated, and the HBase-level factory methods generally ensure they're populated. Phoenix
code should do the same, to maintain the polymorphic contract. This is important in cases
like custom ReplicationEndpoints where HBase-level code may be iterating over WALEdits that
contain both KeyValues and IndexKeyValues and may need to interrogate their contents. 
> Since the index mutation has a row key, this is straightforward. 

This message was sent by Atlassian JIRA

View raw message