[
https://issues.apache.org/jira/browse/HBASE-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-1234.
--------------------------
Resolution: Fixed
Committed v7.
Made issues to address outstanding unit tests broken (disabled) as part of v7
commit.
> Change HBase StoreKey format
> ----------------------------
>
> Key: HBASE-1234
> URL: https://issues.apache.org/jira/browse/HBASE-1234
> Project: Hadoop HBase
> Issue Type: Improvement
> Reporter: stack
> Assignee: stack
> Fix For: 0.20.0
>
> Attachments: 1234-v2.patch, 1234-v5.patch, 1234.patch,
> hbase-1234-v6.patch, hbase-1234-v7.patch
>
>
> HBASE-859 cleaned up keys removing the need of HRegionInfo being in the
> context comparing keys. This issue is about changing the format. Work done
> in HBASE-859 means changes have been localized to HStoreKey, in particular to
> comparators and parse routines. We should do this now since 0.20.0 will
> require rewriting all data.
> Things to consider:
> <row> <columnfamily> <columnqualifier> <timestamp> <keytype>
> Or leave off columnfamily altogether and just write it once into the hfile
> metadata (All key compares are done in the Store context so columnfamily can
> be safely left out of the equation; its only when the key rises above Store
> that the columnfamily needs appending).
> keytype is probably a byte. Types are delete cell, delete row, delete family,
> delete column? What else? Where should we put it? At the end? How should
> type sort? Or should it not be part of sort so its just the order at which
> we encounter the key?
> How are we going to support keys that go in out of chronological order?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
