Cassandra version 0.7.4

 

Hi,

 

I created my own java class as an extension of the AbstractType class.
But I'm not sure about the following items related to the compare
function :

# The remaining bytes of the buffer sometimes is zero during thrift
get_slice execution, however I never store any zero length column name
nor query for it . If normal, what would be the correct handling of the
zero remaining bytes? Would it be something like :

public int compare(ByteBuffer o1, ByteBuffer o2){             

int ar1Rem = o1.remaining();

int ar2Rem = o2.remaining();

if ( ar1Rem == 0 || ar2Rem == 0 ) {

if ( ar1Rem != 0 ) {

                     return 1;

              } else if ( ar2Rem != 0 ) {

                     return -1;

              } else {

                     return 0;

              }

}

//Add the real compare here

.......}

 

# Since in version 0.6.3 the same function was passing an array of
bytes, I assumed that I could now call the ByteBuffer.array() function
in order to get the array of bytes backing up the ByteBuffer. Also the
length of the byte array in 0.6.3 seemed always to correspond to the
bytes of column name stored. But now in version 0.7.4 that ByteBuffer is
not always backed by such an array.

I can still get around this by making the needed buffer myself like :

int ar2Rem = o2.remaining();

byte[] ar2 = new byte[ar2Rem];

o2.get(ar2, 0, ar2Rem);

Question is : Are the remaining bytes the actual bytes for this column
name (eg: 20 bytes) or would that ByteBuffer ever be some wrapper around
some larger stream of data and the remaining bytes number could be 10 M
bytes. Thus I would not be able to detect the end of the column to
compare and I would possibly be allocating a large unneeded byte array?

 

#Using the ByteBuffer's 'get' function also updates the position of the
ByteBuffer. Is the compare function expected to do that or should it
reset the position back to what it was or ...?

 

 

Or maybe there is some good documentation I should read?

 

Ignace

 

Reply via email to