AQL select with PK

Tools AQL
, , ,
4

PK is an internal designation used by AQL for the user specified primary key. For example, in AQL if you insert a record as follows: (Default KEY_SEND is false)

aql> INSERT INTO test.demo (PK, foo, bar) VALUES ('key1', 123, 'abc')
OK, 1 record affected.
aql> select * from test.demo
+-----+-------+
| foo | bar   |
+-----+-------+
| 123 | "abc" |
+-----+-------+
1 row in set (0.588 secs)

Internally, record is stored using the digest which is a hash of setname+yourkey. AQL can read the record using the digest.

aql> set output json
aql> set record_print_metadata true
aql> select * from test.demo
[
  {
    "digest": "7JEZLUt/jONdXXjTS8ply6qqyWA=",   _<== digest in Base64_
    "ttl": 2591505,
    "gen": 1,
    "bins": {
      "foo": 123,
      "bar": "abc"
    }
  }
]

Use EDIGEST for reading records with digest in Base64

aql> select * from test.demo where edigest="7JEZLUt/jONdXXjTS8ply6qqyWA="
[
  {
    "digest": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=",   _<== incorrect value, AQL bug._
    "ttl": 2591487,
    "gen": 1,
    "bins": {
      "foo": 123,
      "bar": "abc"
    }
  }
]

What is the digest in hexadecimal? Here is how to see it.

aql> explain select * from test.demo where PK='key1'
[
  {
    "SET": "demo",
    "DIGEST": "EC 91 19 2D 4B 7F 8C E3 5D 5D 78 D3 4B CA 65 CB AA AA C9 60",
    "NAMESPACE": "test",
    "PARTITION": 492,
    "STATUS": 0,
    "UDF": "FALSE",
    "KEY_TYPE": "STRING",
    "POLICY_REPLICA": "AS_POLICY_REPLICA_MASTER",
    "NODE": "BB96E3DD1290C00",
    "POLICY_KEY": "AS_POLICY_KEY_DEFAULT",
    "TIMEOUT": 1000
  }
]

Use DIGEST now and carefully trim out the spaces from the hexadecimal digest string after pasting. (AQL command key words are case insensitive. namespace and set names etc are case sensitive.)

aql> select * from test.demo where digest="EC91192D4B7F8CE35D5D78D34BCA65CBAAAAC960"
[
  {
    "digest": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=", _<== incorrect value, AQL bug._
    "ttl": 2591369,
    "gen": 1,
    "bins": {
      "foo": 123,
      "bar": "abc"
    }
  }
]

Now if you set key_send to true first, then insert record via AQL, AQL internally (uses C client) sets write policy attribute sendKey to true. Your key (“key2” below) is then stored in the record.

aql> SET KEY_SEND TRUE
aql> INSERT INTO test.demo (PK, foo, bar) VALUES ('key2', 456, 'abc')
OK, 1 record affected.
aql> select * from test.demo where pk='key2'
[
  {
    "PK": "key2",  _<== yourkey stored with the record_
    "digest": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=",  _<== Ignore, AQL bug with WHERE_
    "ttl": 2591981,
    "gen": 1,
    "bins": {
      "foo": 456,
      "bar": "abc"
    }
  }
]

In your example above, in the client, you have used write policy as null. So it is not sending your key to the record. Internally, Aerospike does not store yourkey - it only stores the digest. Obviously, from the digest you cannot recover your key.

Hope this clears it.