Actually, thats not the case:
@Test
public void test() {
Integer lastInt = 0;
byte[] lastBytes = null;
for (int i = -3; i < 3; i++) {
byte[] current = Bytes.toBytes(i);
if (lastBytes != null) {
Assert.isTrue(lastInt.compareTo(i) < 0);
Assert.isTrue(Bytes.compareTo(lastBytes, current) < 0);
}
lastBytes = current;
lastInt = i;
}
}
Fails...
On Tue, Dec 16, 2008 at 2:32 PM, Jonathan Gray <[email protected]> wrote:
> intToBytes is really just a "cast" to bytes, allowing you to store the
> actual binary value of the integer. It would be in increasing numerical
> order.
>
> This is an example of the oddity that is Java...
>
> Great move by using big-endian in the virtual machine, but if you want to
> actually access the binary the JVM is using for an integer you have to
> write
> your own function that uses bitwise operations to extract the value into a
> byte[].
>
> Anyways, the answer is Yes.
>
> JG
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf Of
> > Clint Morgan
> > Sent: Tuesday, December 16, 2008 2:13 PM
> > To: [email protected]
> > Subject: Re: Integer key range scan
> >
> > Does intToBytes preserve ordering? IE is the leicographic ordering of
> > the
> > resulting byte [] the same as the ordering of the original ints?
> >
> > I think Edward needs that for his scan to work...
> >
> > -clint
> >
> > On Tue, Dec 16, 2008 at 1:25 PM, Jonathan Gray <[email protected]>
> > wrote:
> >
> > > I believe there are intToBytes/bytesToInt functions in Bytes.java.
> > Rather
> > > than padding and storing as strings, you can just store as binary
> > numbers.
> > > If you can't find those functions I can send you one of our helper
> > classes
> > > that deals with binary data easily.
> > >
> > > Though this does make things a bit less pretty in web ui/shell it's
> > far
> > > more efficient.
> > >
> > > JG
> > >
> > > > -----Original Message-----
> > > > From: [email protected] [mailto:[email protected]] On Behalf Of
> > Edward
> > > > J. Yoon
> > > > Sent: Tuesday, December 16, 2008 9:39 AM
> > > > To: [email protected]
> > > > Subject: Re: Integer key range scan
> > > >
> > > > Oh Yes, Thanks for tip J-D.
> > > >
> > > > On Wed, Dec 17, 2008 at 2:27 AM, Jean-Daniel Cryans
> > > > <[email protected]> wrote:
> > > > > Yes, then you would scan with startrow = 0000000035 and stoprow =
> > > > 0000000236
> > > > > if this is really what you want to do.
> > > > >
> > > > > J-D
> > > > >
> > > > > On Tue, Dec 16, 2008 at 12:25 PM, Edward J. Yoon
> > > > <[email protected]>wrote:
> > > > >
> > > > >> Like this? 0000000035 ~ 0000000235
> > > > >>
> > > > >> On Wed, Dec 17, 2008 at 2:21 AM, Jean-Daniel Cryans
> > > > <[email protected]>
> > > > >> wrote:
> > > > >> > You can left pad with zeroes then use the scanning facility
> > for
> > > > faster
> > > > >> > retrieval.
> > > > >> >
> > > > >> > J-D
> > > > >> >
> > > > >> > On Tue, Dec 16, 2008 at 12:18 PM, Edward J. Yoon
> > > > <[email protected]
> > > > >> >wrote:
> > > > >> >
> > > > >> >> I would use integer key and extract data from range scans.
> > But,
> > > > hbase
> > > > >> >> row/column is alphabetically sorted.
> > > > >> >>
> > > > >> >> So, I wrote like below:
> > > > >> >>
> > > > >> >> for (int i = 35; i <= 235; i++) {
> > > > >> >> table.getRow(i, columns[]);
> > > > >> >> }
> > > > >> >>
> > > > >> >> It seems, causes too many requests over hbase.
> > > > >> >> Any suggestion?
> > > > >> >>
> > > > >> >> --
> > > > >> >> Best Regards, Edward J. Yoon @ NHN, corp.
> > > > >> >> [email protected]
> > > > >> >> http://blog.udanax.org
> > > > >> >>
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Best Regards, Edward J. Yoon @ NHN, corp.
> > > > >> [email protected]
> > > > >> http://blog.udanax.org
> > > > >>
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Edward J. Yoon @ NHN, corp.
> > > > [email protected]
> > > > http://blog.udanax.org
> > >
> > >
>
>
