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 0x6e6562@gmail.com designates
 209.85.128.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAKv2g8dQw3Fw6MhWh6qj7HKyfdmq7jdsCuc9pidW_ethkms6=w@mail.gmail.com>
References: 
 <CAB-G1jjxZopJ98+qv0vGodFcA_5H1M9R6A_vuFzCgW2q16vj+A@mail.gmail.com>
	<CAKv2g8dQw3Fw6MhWh6qj7HKyfdmq7jdsCuc9pidW_ethkms6=w@mail.gmail.com>
Date: Mon, 24 Feb 2014 17:51:54 +0000
Message-ID: 
 <CAB-G1jj=DUa+JxE66ozyWxxivOFxFOSvhXbysWDhRoOLhrGcNA@mail.gmail.com>
Subject: Re: CQL decimal encoding
From: Ben Hood <0x6e6562@gmail.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Hey Peter,

On Mon, Feb 24, 2014 at 5:25 PM, Peter Lin <woolfel@gmail.com> wrote:
>
> Not sure what you mean by the question.
>
> Are you talking about the structure of BigDecimal in java? If that is your
> question, the java's BigDecimal uses the first 4 bytes for scale and
> remaining bytes for BigInteger

I'm talking about the encoding of an arbitrary precision value in a
platform neutral fashion such that interoperability between different
language bindings is assured.

Say you have an Java app writing to Cassandra and a Python app reading
this data back out - ideally all language bindings would pack and
unpack the data in an interoperable fashion. Also, I'm not sure what
restrictions the server imposes on the encoding of the decimal type -
can you for example just write any old (unchecked) bogus data into a
decimal column via CQL?

My situation is that I'm implementing the marshalling for the gocql
driver, which is a generic CQL driver for Go. So ideally I'd like to
provide an implementation that is generic across all applications.

I'm using the class big.Rat from the Go standard library, which
provides a similar interface to BigDecimal in Java and decimal.Decimal
in Python. It has it's own encoding/decoding functions, but this
format is specific to Go binary encoding and hence is not portable.

So I have taken cue from 4 byte scale/variable length numerator
strategy used by the Java BigDecimal and I've got something going
using that: https://github.com/gocql/gocql/pull/120

I guess I was looking for some kind of spec for the on-wire format of
the decimal type.

Or in the absence of a spec, just a heads up from other language
driver implementors as to what approach they've taken.

Does this make sense?

Cheers,

Ben