Issue in java client v3.0.34 : Values class

Client Libraries Java Client
1

Hi ,

There is an issue in newer client version where DoubleValue is introduced. (earlier double values were added as BlobValue)

Now while reading it is read as Long object.

Eg. :

 AerospikeClient client = new AerospikeClient("127.0.0.1", 3000); 
 // Write a single value.
 Key key = new Key("test", "testset", "checkobject");

 client.put(null, key, new Bin("bin1", 0.5665d));
 Record record = client.get(null, key);
 for (Entry<String, Object> host : record.bins.entrySet()) {
        System.out.println("BinName : " + host.getKey() + " , Value : " + host.getValue() + " , Type: " + host.getValue().getClass().getName());
 }
 System.exit(0);

Output :

   BinName : bin1 , Value : 4603277797923087188 , Type: java.lang.Long

Regards, Holmes

2

Update :

Value read at following line - ReadCommand.java:174 (v3.0.34)

Object value = Buffer.bytesToParticle(particleType, dataBuffer, receiveOffset, particleBytesSize);
3

Can you help and do a backup http://www.aerospike.com/docs/tools/backup/ to see what the data type of “bin1”?

Thanks.

4

Hi Wei-Ling,

Please find the output of backup :

Version 3.0
+ n test
+ d 8GDpo1unCjSsNx3XiEwStZNKg30=
+ s testset
+ g 8
+ t 166545804
+ b 2
- I bin1 4603277797923087188
- I ikb1 4603277797923087188

Regards, Holmes

5

Were you guys able to reproduce it ?
Is it an issue in newer client OR I am doing something wrong ?

Client - 3.0.34
Server - 3.4.1

Regards ,
Holmes

6

The server does not natively support doubles, so the client sends the double as a 64 bit integer to the server. This is much more efficient than sending as a java serialized blob (old way) and more portable too. No bit conversion is made, so there is no loss of precision. This approach does require that:

  1. The client must use “record.getDouble()” to retrieve the value. getDouble() interprets the 64 bits as a double instead of a long.

  2. User defined functions on the server should not manipulate the value because it will appear as a long.

If these constraints are not acceptable, you can always convert the double to a byte and write as a blob.

1 Like
7

We are scheduling native double support for the server for soon delivery.

As an aside, doubles have many properties that most programmers are unaware of - such as 0.1 + 0.2 is not 0.3 , and you can’t compare doubles using ‘=’ . I find most programmers really want forms of fixed point, and are best served by string representation instead of trying to use integers. Then, one often uses a fixed-point-string library.

For these reasons, floating point isn’t used for currency.

Here’s a guide I find useful:

Programmers often want base-10 floating point instead of base-2 floating point. There is a new standard proposed as a part of IEEE 754 called “decimal64” floating point which does exactly what most programmers want. It’ll take a long, long time for that format to get implemented in chips, then languages. I look forward to that day.

There are valid use cases for binary (base-2) floating point ( like scoring in recommendation engines, where sin() is used ), and if you’ve got a valid use, I’m sorry you’ll have to live with a workaround for a while.

1 Like