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 <0x6e6...@gmail.com> wrote: > Hey Peter, > > On Mon, Feb 24, 2014 at 5:25 PM, Peter Lin <wool...@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 >
