# Incomplete key retrieval **URL:** \ **Category:** Python Client\ **Created:** [March 3, 2016, 12:08am UTC](https://discuss.aerospike.com/t/incomplete-key-retrieval/2583 "2016-03-03T00:08:14Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![dfc](https://avatars.discourse-cdn.com/v4/letter/d/ecae2f/32.png) [@dfc](https://discuss.aerospike.com/u/dfc)\ **Post date:** [March 3, 2016, 12:08am UTC](https://discuss.aerospike.com/t/incomplete-key-retrieval/2583/1 "2016-03-03T00:08:14Z")
Hi, Using Python (2 or 3 doesn’t change anything), I unable to “get” the primary key which was used for “put”. I started to see the problem when I decided to scan a ‘set’ and found all primary-keys set to ‘None’. I initially thought it was my fault, but I managed to reproduce the problem with the “standard” Python example. Here is part of the code : … # Records are addressable via a tuple of (namespace, set, key) key = (‘test’, ‘demo’, ‘foo’) try: # Write a record client.put(key, { ‘name’: ‘John Doe’, ‘age’: 32 }) except Exception as e: import sys print(“error: {0}”.format(e), file=sys.stderr) (key, metadata, record) = client.get(key) print(key, record) The output looks like this : (‘test’, ‘demo’, None, bytearray(b’\xf5~\xc1\x835\xf7\x10\x0c\x04X\xf8\xa6D\xbc\xbcvm\x93G\x1e’)) {‘age’: 32, ‘name’: ‘John Doe’} As you can see, the returned primary-key is set to None, while it should be set to ‘foo’. Did I miss something ? ---
**Author:** ![rbotzer](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/rbotzer/32/2114_2.png) [@rbotzer](https://discuss.aerospike.com/u/rbotzer)\ **Post date:** [March 3, 2016, 12:40am UTC](https://discuss.aerospike.com/t/incomplete-key-retrieval/2583/2 "2016-03-03T00:40:50Z")
Hi Daniel, By default the _key_ portion of the [key tuple](http://www.aerospike.com/apidocs/python/client.html#aerospike-key-tuple) is not saved, because it would cost extra in storage space. The key [write policy](http://www.aerospike.com/apidocs/python/client.html#write-policies) controls this behavior, and you can modify it when you call [`aerospike.Client.put`](http://www.aerospike.com/apidocs/python/client.html#aerospike.Client.put). Look at the example provided in the doc for that method. Once the key is [stored](http://www.aerospike.com/apidocs/python/aerospike.html#aerospike.POLICY_KEY_SEND) with the record, it will show up in subsequent [`aerospike.Client.get`](http://www.aerospike.com/apidocs/python/client.html#aerospike.Client.get), [scan](http://www.aerospike.com/apidocs/python/scan.html), and [query](http://www.aerospike.com/apidocs/python/query.html) operations. ---
**Author:** ![dfc](https://avatars.discourse-cdn.com/v4/letter/d/ecae2f/32.png) [@dfc](https://discuss.aerospike.com/u/dfc)\ **Post date:** [March 3, 2016, 10:08am UTC](https://discuss.aerospike.com/t/incomplete-key-retrieval/2583/3 "2016-03-03T10:08:28Z")
Hi Ronen, I tried to use ‘DIGEST’ key attributes, describes in : [http://www.aerospike.com/docs/guide/policies.html](http://www.aerospike.com/docs/guide/policies.html), since it’s what’s recommended : “**DIGEST—Calculate (on the client) and send the digest value of key to the server. We recommend using this mode of operation.**” However, it has no effect… Besides, while I perfectly understand the technical reason behind this strategy, I have the feeling that the documentation is not very clear about it. Like… “**Indexes (primary keys and secondary keys) are stored in DRAM for ultra-fast access**”, found in [http://www.aerospike.com/docs/architecture/](http://www.aerospike.com/docs/architecture/) and “**(Index Persistence) To maintain throughput, primary indexes are not committed to storage—only to RAM**” in [http://www.aerospike.com/docs/architecture/primary-index.html](http://www.aerospike.com/docs/architecture/primary-index.html) Though, if it’s stored in DRAM, why is that I don’t have it with a _client.get()_ I had the false impression that indexes could be accessed any way… Anyway, it finally worked using the SEND policy, but I still don’t understand the subtle difference between DIGEST and SEND regarding key storage… besides the ‘digest’ itself. Thank’s for your help ---
**Author:** ![rbotzer](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/rbotzer/32/2114_2.png) [@rbotzer](https://discuss.aerospike.com/u/rbotzer)\ **Post date:** [March 3, 2016, 1:54pm UTC](https://discuss.aerospike.com/t/incomplete-key-retrieval/2583/4 "2016-03-03T13:54:32Z")
Sorry, I should have been more explicit. `aerospike.KEY_DIGEST` is the default (‘just the digest’) and `aerospike.KEY_SEND` is the optional alternative value, which means store the key along with the bin data. In both the primary index and secondary index the metadata is stored in DRAM, regardless of what storage device you have for the data, but the key, like bins, are stored as data (not in the index). Glad it’s working.