[
https://issues.apache.org/jira/browse/HBASE-9283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated HBASE-9283:
--------------------------------
Description:
For a composite row key, Phoenix strips off trailing null columns values in the
row key. The reason this is important is that then new nullable row key columns
can be added to a schema without requiring any data upgrade to existing rows.
Otherwise, adding new row key columns to the end of a schema becomes extremely
cumbersome, as you'd need to delete all existing rows and add them back with a
row key that includes a null value.
Rather than Phoenix needing to modify the iteration code everywhere (as
[~ndimiduk] outlined here:
https://issues.apache.org/jira/browse/HBASE-8693?focusedCommentId=13744499&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13744499),
it'd be better if StructIterator handled this out-of-the-box. Otherwise, if
Phoenix has to specialize this, we'd lose the interop piece which is the
justification for switching our type system to this new one in the first place.
was:For [~giacomotaylor] to fill in.
> Struct and StructIterator should properly handle trailing nulls
> ---------------------------------------------------------------
>
> Key: HBASE-9283
> URL: https://issues.apache.org/jira/browse/HBASE-9283
> Project: HBase
> Issue Type: Bug
> Reporter: Nick Dimiduk
>
> For a composite row key, Phoenix strips off trailing null columns values in
> the row key. The reason this is important is that then new nullable row key
> columns can be added to a schema without requiring any data upgrade to
> existing rows. Otherwise, adding new row key columns to the end of a schema
> becomes extremely cumbersome, as you'd need to delete all existing rows and
> add them back with a row key that includes a null value.
> Rather than Phoenix needing to modify the iteration code everywhere (as
> [~ndimiduk] outlined here:
> https://issues.apache.org/jira/browse/HBASE-8693?focusedCommentId=13744499&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13744499),
> it'd be better if StructIterator handled this out-of-the-box. Otherwise, if
> Phoenix has to specialize this, we'd lose the interop piece which is the
> justification for switching our type system to this new one in the first
> place.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
