Hey Ben,

It looks like you are trying to implement the Decimal type. You might
want to start with implementing the Integer type. The Decimal type
follows pretty easily from the Integer type.

For example:
i = unmarchalInteger(data[4:])
s = decInt(data[0:4])
out = inf.newDec(i, s)

On 02/24/2014 09:51 AM, Ben Hood 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


-- 
*Colin Blower*
/Software Engineer/
Barracuda Networks Inc.
+1 408-342-5576 (o)

===========================================================

Find out how eSigning generates significant financial benefit.
Read the Barracuda SignNow ROI whitepaper at 
https://signnow.com/l/business/esignature_roi

Reply via email to