if I have time this week, I'll try to make a patch for the spec. Can't promise I can get to it this week, but having come across this issue with FluentCassandra, I'd like to help others avoid it.
On Tue, Feb 25, 2014 at 5:38 AM, Sylvain Lebresne <sylv...@datastax.com>wrote: > On Mon, Feb 24, 2014 at 8:50 PM, Theo Hultberg <t...@iconara.net> wrote: > >> I don't know if it's by design or if it's by oversight that the data >> types aren't part of the binary protocol specification. >> > > 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. > > 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)). > > -- > Sylvain > > > >> I had to reverse engineer how to encode and decode all of them for the >> Ruby driver. There were definitely a few bugs in the first few versions >> that could have been avoided if there was a specification available. >> >> T# >> >> >> On Mon, Feb 24, 2014 at 8:43 PM, Paul "LeoNerd" Evans < >> leon...@leonerd.org.uk> wrote: >> >>> On Mon, 24 Feb 2014 19:14:48 +0000 >>> Ben Hood <0x6e6...@gmail.com> wrote: >>> >>> > So I have a question about the encoding of 0: \x00\x00\x00\x00\x00. >>> >>> The first four octets are the decimal shift (0), and the remaining ones >>> (one in this case) encode a varint - 0 in this case. So it's >>> >>> 0 * 10**0 >>> >>> literally zero. >>> >>> Technically the decimal shift matters not for zero - any four bytes >>> could be given as the shift, ending in \x00, but 0 is the simplest. >>> >>> -- >>> Paul "LeoNerd" Evans >>> >>> leon...@leonerd.org.uk >>> ICQ# 4135350 | Registered Linux# 179460 >>> http://www.leonerd.org.uk/ >>> >> >> >
