[
https://issues.apache.org/jira/browse/PHOENIX-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792889#comment-16792889
]
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: https://issues.apache.org/jira/browse/PHOENIX-5188
> 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, 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
(v7.6.3#76005)