Meaning of edigest field being "n/a" in a record?

[iandntran]

Hi, I noticed that in a select query I ran, with record print metadata set to true, the edigest of the field was set to “n/a”.

I thought the digest is always calculated using the primary key, or is it dependent on some particular usage of the aerospike client API?

Output below: set record_print_metadata true RECORD_PRINT_METADATA = true select * from ns1.testtable where PK=‘abcde’

[ [ { “edigest”: “N/A”, “ttl”: -1, “gen”: 1, “bins”: { “key”: 193654784047579649 } } ], [ { “Status”: 0 } ] ]

Any info is appreciated, Thanks

[pgupta]

When you read one specific record, server does not send the digest back. You have the key ‘abcde’, you have the set name. You can use the client API to calculate the digest. For example, see Java client API - computeDigest(). This is to eliminate unnecessary data movement between client and server. However, if you do a query, i.e. select * without where PK='abcde', you should see the eDigest returned by the server for all the records that are returned by the query. There is no functional need to return edigest for a single record read. Its only academic.

[pgupta]

See below… for a query returning 10 records:

[training@ip-172-31-3-62 jn]$ aql
Seed:         127.0.0.1
User:         None
Config File:  /etc/aerospike/astools.conf /home/training/.aerospike/astools.conf 
Aerospike Query Client
Version 9.1.0
aql> set record_print_metadata true
RECORD_PRINT_METADATA = true
aql> select * from test.testset
+--------+----------+-----+--------------------------------+-----------+--------+-------+
| PK     | name     | age | {edigest}                      | {set}     | {ttl}  | {gen} |
+--------+----------+-----+--------------------------------+-----------+--------+-------+
| "key7" | "Sean"   | 24  | "GrW7WKHR4X3POYqAOd3Qn3RgYGo=" | "testset" | 431966 | 1     |
| "key9" | "Susan"  | 42  | "z09xqdn15z/8ZA44fHfAo7mOEWQ=" | "testset" | 431966 | 1     |
| "key6" | "Sally"  | 32  | "9wiNahMzzTktJuuDLjIXML42UVA=" | "testset" | 431966 | 1     |
| "key5" | "Julia"  | 62  | "QjpKMijsCAB3vojQoK8WSSaieX0=" | "testset" | 431966 | 1     |
| "key0" | "Sandra" | 34  | "GOtCn0TBY53UxQoC+9OAZA6thrQ=" | "testset" | 431966 | 1     |
| "key2" | "Jill"   | 20  | "wQssdk5gTEOQOYBOyUf6KxhSDRo=" | "testset" | 431966 | 1     |
| "key4" | "Jim"    | 46  | "cDykoDBoxXFxvEvh+Cn83WBMzcU=" | "testset" | 431966 | 1     |
| "key1" | "Jack"   | 26  | "v2wdE+fNEMW9Ai0n598XDAvM1uE=" | "testset" | 431966 | 1     |
| "key8" | "Sam"    | 12  | "3HycFV/Y8HlzsMWgGt3zkK2MRuk=" | "testset" | 431966 | 1     |
| "key3" | "James"  | 38  | "EP2PWa3xgzFS5Dmi4DwZ78sSwUU=" | "testset" | 431966 | 1     |
+--------+----------+-----+--------------------------------+-----------+--------+-------+
10 rows in set (0.067 secs)

OK

aql> 

But for a specific record:

aql> select * from test.testset where pk="key1"
+--------+--------+-----+--------+-------+
| PK     | name   | age | {ttl}  | {gen} |
+--------+--------+-----+--------+-------+
| "key1" | "Jack" | 26  | 431883 | 1     |
+--------+--------+-----+--------+-------+
1 row in set (0.001 secs)

OK

It’s not a bug, it’s a feature.

[iandntran]

Thank you for the information!