[ 
https://issues.apache.org/jira/browse/HBASE-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-1234:
-------------------------

    Attachment: 1234-v2.patch

In v2, all compiles now.  Next, I need to do tests.

This patch actually deprecates HSK.

KeyValue.KVComparators now have a RawComparator<byte []> that can do the Key 
portion only.  We needed these mostly so we could talk about RawComparator only 
in hfile without having to have it know all about KeyValue Comparators.

I cleaned up KeyValue some.  Removes all the KV.create and made constructors 
instead.  Seemed cleaner than sometimes static create and others a constructor.

Filter interface has changed to you pass byte array, offset, and row tuples 
instead of just a byte array.





> 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.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.

Reply via email to