Has anyone verified that the shell works after this patch? I applied and tried to run a simple select statement, but it does not want to work for me.
On Thu, May 15, 2008 at 3:14 PM, stack (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/HBASE-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > stack updated HBASE-82: > ----------------------- > > Resolution: Fixed > Status: Resolved (was: Patch Available) > > Committed. > >> row keys should be array of bytes >> --------------------------------- >> >> Key: HBASE-82 >> URL: https://issues.apache.org/jira/browse/HBASE-82 >> Project: Hadoop HBase >> Issue Type: Wish >> Reporter: Jim Kellerman >> Assignee: stack >> Fix For: 0.2.0 >> >> Attachments: 82-v12-ignore-ws.patch, 82-v13-ignore-ws.patch, >> 82-v2.patch, 82-v3.patch, 82-v4.patch, 82-v5.patch, 82-v7.patch, >> 82-v8.patch, 82-v9-ignore-ws.patch, 82.patch, Perf.java >> >> >> 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. > >
