phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoffrey Jacoby (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-5188) IndexedKeyValue should populate KeyValue fields
Date Thu, 14 Mar 2019 17:24:00 GMT


Geoffrey Jacoby commented on PHOENIX-5188:

[~xucang] - Not sure the addendum is really necessary. It appears that the only place where
the default constructor is used is immediately prior to deserialization in KeyValueCodec,
and at that point _all_ the fields are in an unusable state. The default constructor's really
only usable if you then deserialize, at which point the default empty byte array the addendum
adds will be overwritten.

I put the initialization of the bytes, offset, and length fields in the deserialization code
itself rather than the default constructor, because in the default constructor we don't have
the mutation to get the correct byte array yet. 

> 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
>             Fix For: 4.15.0, 5.1
>         Attachments: PHOENIX-5188-4.x-HBase-1.4..addendum.patch, PHOENIX-5188-4.x-HBase-1.4.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