incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Lin <>
Subject Re: CQL decimal encoding
Date Mon, 24 Feb 2014 18:09:24 GMT
ok, I "think" I understand.

I took a look at the code. Java uses big endian encoding. I don't know if
GO defaults to big or little. In my port of Hector to C#, I reverse the
bytes due to the fact that .Net uses little endian.

hope that helps

On Mon, Feb 24, 2014 at 12:51 PM, Ben Hood <> wrote:

> Hey Peter,
> On Mon, Feb 24, 2014 at 5:25 PM, Peter Lin <> 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:
> 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

View raw message