Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of sylvain@datastax.com designates
 209.85.218.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <15FEFA0410B1AA4F9775D72F0279A368B27100@EU-EXCH02.nuance.com>
References: <15FEFA0410B1AA4F9775D72F0279A368B27100@EU-EXCH02.nuance.com>
Date: Wed, 20 Apr 2011 14:06:39 +0200
Message-ID: <BANLkTi=x7CeEr62EG0fg3Hpukd1ZaSwyAQ@mail.gmail.com>
Subject: Re: Question about AbstractType class
From: Sylvain Lebresne <sylvain@datastax.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 20, 2011 at 1:35 PM, Desimpel, Ignace
<Ignace.Desimpel@nuance.com> wrote:
> Cassandra version 0.7.4
>
>
>
> Hi,
>
>
>
> I created my own java class as an extension of the AbstractType class. Bu=
t
> I=92m 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 no=
r
> query for it . If normal, what would be the correct handling of the zero
> remaining bytes?

It is normal, the empty ByteBuffer is used in slice queries to indicate the
beginning of the row (start=3D""). More generally, compare and validate
should work for anything you store but also anything you provide for
the 'start'
and 'end' argument of slices.

> Would it be something like :
>
> public int compare(ByteBuffer o1, ByteBuffer o2){
> int ar1Rem =3D o1.remaining();
> int ar2Rem =3D o2.remaining();
> if ( ar1Rem =3D=3D 0 || ar2Rem =3D=3D 0 ) {
> if ( ar1Rem !=3D 0 ) {
> =A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0 return 1;
> =A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0 } else if ( ar2Rem !=3D 0 ) {
> =A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0 return -1;
> =A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0 } else {
> =A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0 return 0;
> =A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0 }
> }
> //Add the real compare here
> =85=85.}

That looks reasonable (though not optimal in the number of comparison :))

> # 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.

It's not that simple. First, even if you use ByteBuffer.array(),
you'll have to be
careful that the ByteBuffer has a position, a limit and an arrayOffset and =
you
should take that into account when accessing the backing array. But there i=
s
also no guarantee that the ByteBuffer will have a backing array so you need=
 to
handle this case too (I refer you to the ByteBuffer documentation).

> Also the length of the
> byte array in 0.6.3 seemed always to correspond to the bytes of column na=
me
> 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 =3D o2.remaining();
>> byte[] ar2 =3D new byte[ar2Rem];
>> o2.get(ar2, 0, ar2Rem);
>
> Question is : Are the remaining bytes the actual bytes for this column na=
me
> (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?

As said above, the remaing bytes won't (always) be the actual bytes.

> #Using the ByteBuffer=92s =91get=92 function also updates the position of=
 the
> ByteBuffer. Is the compare function expected to do that or should it rese=
t
> the position back to what it was or =85?

Neither. You should *not* use any function that change the ByteBuffer posit=
ion.
That is, changing it and resetting it afterward is *not* ok.
Instead you should only use only the absolute get() methods, that do
not change the
position at all.
Or, you start your compare function by calling BB.duplicate() on both
buffers and
then you're free to change the position of the duplicates.

--
Sylvain