Sylvain, On Tue, Feb 25, 2014 at 10:38 AM, Sylvain Lebresne <sylv...@datastax.com> wrote: > The honest answer is, no-one took the time to write that down properly and > include it in the spec. My small excuse for initially skipping it in the > spec is that the CQL data type encodings are really not different from what > we have had in thrift since forever, so that there is already many driver in > a lot of language out there that have encoding/decoding functions for them > that can be looked at. But if someone find some time to gather all those > encoding and provides a patch for the spec with them, that would > definitively be much appreciated. Cassandra is an open-source software, > everyone can contribute, and that does not exclude documentation and > specifications.
I totally get this and I don't see myself or other CQL driver authors taking the time to submit a pull request for this either :-\ Also, I've never come across that a spec that has been complete or even bug free before a bunch of people tried to implement it - I guess this just happens with living systems. > Regarding the decimal, it does uses 4 bytes for the scale and the rest for > the bytes of the unscaled value (i.e. a variable length integer) as Peter > mentioned. the actual value being the "unscaled value" * 10^-"scale" > (internally C* really just use the following BigDecimal ctor: > http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html#BigDecimal(java.math.BigInteger, > int)). Thanks for the clarification. A lot of the issues I was running into was trying to use a type from the Golang standard library that looks similar to BigDecimal, but doesn't let you set the scale in a way that would permit wire level interoperability. There is an alternative implementation, albeit not in the standard library, which will work in the way that BigDecimal works. So I'm going to run this approach past the other maintainers of gocql to see what they think about pulling in a 3rd party library into the driver. Ben
