Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


BigDecimal is incorrect #83

woolfel opened this Issue · 2 comments

2 participants

Peter Lin Nick Berardi
Peter Lin

The way cassandra stores and uses BigDecimal is reverse from what you have. The first 4 bytes is the scale and the remaining bytes are the BigInteger.

Even though this will store properly for .Net, the minute someone tries to use cassandra-cli or cqlsh, it will result in java heap space error and crash. If people are reading data from other platforms like java or python, it will be wrong.

Nick Berardi nberardi referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
Nick Berardi

Please review the byte output to make sure that they are in the proper order and the sections are facing the right way for their endianess.

private readonly BigDecimal bigDecimal = 100002334.4563D;
private readonly byte[] dotNetByteOrder = new byte[] { 179, 69, 9, 214, 232, 0, 4, 0, 0, 0 };
private readonly byte[] javaByteOrder = new byte[] { 0, 0, 0, 4, 0, 232, 214, 9, 69, 179 };

This is taken from the following test, please update the test with the correct values if the assumptions are wrong.


Nick Berardi nberardi was assigned
Nick Berardi

Closing since there hasn't been any response.

Nick Berardi nberardi closed this
achinn achinn referenced this issue from a commit in achinn/fluentcassandra
Alex Chinn Fixed regression caused by fix to issue #83. If a null value is found…
… in a decimal type column then you'll get a NullReferenceException when reading it out.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.