[
https://issues.apache.org/jira/browse/HBASE-7221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509521#comment-13509521
]
Elliott Clark commented on HBASE-7221:
--------------------------------------
I still am against naming anything RowKey. It just invites confusion. I don't
think that there's any plan to support passing these objects as a row key. So
in my opinion they shouldn't be named that way. When a user searches on
google/bing/duck duck go for hbase row key they should get the documentation
about how they should structure a row key not some class that's named row key,
but isn't actually the type to be passed in as a row key.
Why not a more general builder style ?
{code:java}
//Could just use magic numbers to represent replace. Not sure how I feel about
that
enum HashPosition {
PREPEND,
APPEND,
REPLACE
}
enum Order {
ASSENDING, //Smaller Numbers first
DESCENGING //Larger numbers first
}
class CompositeRowKeyBuilder {
public CompositeRowKeyBuilder();
public CompositeRowKeyBuilder(int numFields); //throw exception if the number
of fields is off when build is called.
public CompositeRowKeyBuilder(int numFields, int expectedBytes); //Same as
above but allows for hint to ByteBuffer.
private ByteBuffer bb = new ByteBuffer();
public CompositeRowKeyBuilder addHash(Hash hash, HashPosition position);
public CompositeRowKeyBuilder add(String s);
public CompositeRowKeyBuilder add(String s, int length); //We should be
trying to encourage fixed keys if possible
public CompositeRowKeyBuilder add(Int i);
public CompositeRowKeyBuilder add(Int i, Order o);
public CompositeRowKeyBuilder add(Long l);
public CompositeRowKeyBuilder add(Long l, Order o);
public CompositeRowKeyBuilder add(Double d); //Use something like Orderly's()
formatting allowing the sorting of double and float
public CompositeRowKeyBuilder add(Double d, Order o);
public CompositeRowKeyBuilder add(Float f);
public CompositeRowKeyBuilder add(Float f, Order o);
public CompositeRowKeyBuilder add(byte[] bytes);
public byte[] build(); //yes I know this breaks the builder pattern a little
bit. But I think it's worth it.
}
class ExamplUsage {
public static void main(String[]args) {
CompositeRowKeyBuilder builder = new Builder();
//rk should = MURUMUR_HASH("TestString".getBytes + 100.toBytes) +
"TestString".getBytes + 100.getBytes
byte[] rk = builder.addHash(Hash.MURUMUR,
PREPEND).add(100).add("TestString").build()
//rkTwo = "MyOtherTestString".reverse().getBytes.
byte[] rkTwo = builder.setHash(Hash.REVERSE,
REPLACE).add("MyOtherTestString").build()
}
}
{code}
Thoughts ?
> RowKey utility class for rowkey construction
> --------------------------------------------
>
> Key: HBASE-7221
> URL: https://issues.apache.org/jira/browse/HBASE-7221
> Project: HBase
> Issue Type: Improvement
> Reporter: Doug Meil
> Assignee: Doug Meil
> Priority: Minor
> Attachments: HBASE_7221.patch, hbase-common_hbase_7221_2.patch,
> hbase-common_hbase_7221_v3.patch
>
>
> A common question in the dist-lists is how to construct rowkeys, particularly
> composite keys. Put/Get/Scan specifies byte[] as the rowkey, but it's up to
> you to sensibly populate that byte-array, and that's where things tend to go
> off the rails.
> The intent of this RowKey utility class isn't meant to add functionality into
> Put/Get/Scan, but rather make it simpler for folks to construct said arrays.
> Example:
> {code}
> RowKey key = RowKey.create(RowKey.SIZEOF_MD5_HASH + RowKey.SIZEOF_LONG);
> key.addHash(a);
> key.add(b);
> byte bytes[] = key.getBytes();
> {code}
--
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
