[
https://issues.apache.org/jira/browse/HBASE-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569335#action_12569335
]
stack commented on HBASE-82:
----------------------------
Couple of comments:
+ Extending comment 08/Jan/08 11:18 AM above (how to prevent user entering
different key types), since columns have no types in hbase and column family is
the lowest level of granularity on which we can set attributes, this would
imply that the key type would need to be an attribute of column family. An
attempt at adding a key that was of a different type should throw an exception
(As MR input types do)?
+ I like byte arrays for keys. Aligns w/ a notion I have that hbase should be
as dumb as possible, but no dumber -- as Einstein said once? I like the
reminder that this is how bdb does it. Would it work? For jaql? Client-side,
they'd pass a byte array for row key. Internally we'd just be be doing byte
compares (Though I think thats all we're currently doing with our Text keys).
+ ImmutableByteArray is already a WritableCompable
> [hbase] VOTE: should row keys be less restrictive than hadoop.io.Text?
> ----------------------------------------------------------------------
>
> Key: HBASE-82
> URL: https://issues.apache.org/jira/browse/HBASE-82
> Project: Hadoop HBase
> Issue Type: Wish
> Reporter: Jim Kellerman
>
> I have heard from several people that row keys in HBase should be less
> restricted than hadoop.io.Text.
> What do you think?
> At the very least, a row key has to be a WritableComparable. This would lead
> to the most general case being either hadoop.io.BytesWritable or
> hbase.io.ImmutableBytesWritable. The primary difference between these two
> classes is that hadoop.io.BytesWritable by default allocates 100 bytes and if
> you do not pay attention to the length, (BytesWritable.getSize()), converting
> a String to a BytesWritable and vice versa can become problematic.
> hbase.io.ImmutableBytesWritable, in contrast only allocates as many bytes as
> you pass in and then does not allow the size to be changed.
> If we were to change from Text to a non-text key, my preference would be for
> ImmutableBytesWritable, because it has a fixed size once set, and operations
> like get, etc do not have to something like System.arrayCopy where you
> specify the number of bytes to copy.
> Your comments, questions are welcome on this issue. If we receive enough
> feedback that Text is too restrictive, we are willing to change it, but we
> need to hear what would be the most useful thing to change it to as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
