-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release/babylon 1.4.0 - > main #646
Changes from 1 commit
0bf2f9f
a15acfc
faa1472
caf0f9c
9fc8cde
e1c6f65
4030a66
06b281a
91dd77a
e3c74fa
850099e
c33e4b3
ec0152b
6222855
86431a6
556190c
f795335
99c15c9
fc34e01
a0273ee
31b2728
a01c6c8
2805b51
950607d
9d102cf
c7fc164
a3cf582
2d79f8b
d2ec5c0
bc5c5f2
887e924
499332c
b99d632
a233338
0ea2fbd
66d53e1
e67357c
729bb25
f0e138e
613d1cf
2635a73
133e7f1
1cc2114
db85bbc
e5a07eb
24b667a
462dff2
322dbcc
a672a16
f229383
8e87549
aade6fc
81b3ece
3976358
a4e014d
63c9476
aa46f1c
141d53a
104267b
32c387a
08596c4
c5eb83e
d4ad76c
9be6ab2
355311c
ab53b58
d7f1535
515230a
3bc1146
4480314
4b1d774
8d4a260
8174de2
498bec7
ca4a243
275d68b
b97a1ba
0eedf22
bcd1d5c
921026a
0bb3141
84fc87d
e8781d3
e39cd9c
234050b
afa3d9e
06cef12
488117a
ad45fcd
225217c
dbb492d
513db23
9105d5b
ac49776
9afb130
712cf67
7ee04a5
f4d94a9
23b2028
4829f19
4255ed9
7c90d59
c12b446
a0d1eb2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -879,11 +879,99 @@ tags: | |
} | ||
``` | ||
|
||
### Iterating over all key value store keys | ||
|
||
You can use `/state/key-value-store/keys` endpoint to iterate over all keys in certain key value store. | ||
If the queried key value store contains more than one page of keys, a next_cursor will be returned, which can be used as cursor in the request to fetch further pages. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Minor English article corrections:
|
||
|
||
i.e: | ||
``` | ||
/state/key-value-store/keys | ||
|
||
{ | ||
"key_value_store_address": "internal_keyvaluestore_tdx_2_1kzjd929eqlzd9n02uuj8jd48705vcrpvhv4mgxnaltrgystnca3qxk" | ||
} | ||
``` | ||
|
||
Will respond with list of all keys (in both `hex` and `programmatic_json` form) and state version when they were last updated. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Minor English article corrections:
However(!) I'd suggest we say it's actually not all keys - it's importantly the first page of keys, and we should explain how it's ordered too. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. how about
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I suggest this tweak, if you're happy with it?
|
||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also - just to verify - if a key value store entry is deleted, what happens? I think it's still returned by this API? Or do we filter them out? If it doesn't filter them out, we should explain that this API doesn't do so, and explain how the entry read endpoint handles us looking up a key of an entry that's been deleted. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we filter out deleted keys. do we want to document that somehow? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think if we rewrite as per my other message, and say "current entries", this implies deleted keys aren't returned. |
||
``` | ||
{ | ||
... | ||
"total_count": 8, | ||
"items": [ | ||
{ | ||
"key": { | ||
"raw_hex": "5c0c0131", | ||
"programmatic_json": { | ||
"value": "1", | ||
"kind": "String" | ||
} | ||
}, | ||
"last_updated_at_state_version": 4939670 | ||
}, | ||
... | ||
], | ||
"key_value_store_address": "internal_keyvaluestore_tdx_2_1kzjd929eqlzd9n02uuj8jd48705vcrpvhv4mgxnaltrgystnca3qxk" | ||
} | ||
``` | ||
|
||
### Querying for the content under specific keys | ||
|
||
After that you can use `/state/key-value-store/data` endpoint to query the content for given keys. To do that you can either use key in form of `json` or `hex`. | ||
You can either rely on keys returned from `/state/key-value-store/keys` endpoint or construct keys in json form on your own. It's possible if you created that key value store and you know what is the form of keys. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Suggested:
|
||
|
||
#### Querying using hex keys | ||
|
||
Simply grab `raw_hex` key returned from `/state/key-value-store/keys` endpoint and call `/state/key-value-store/data` with it as parameter. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
|
||
i.e: | ||
``` | ||
/state/key-value-store/data | ||
|
||
{ | ||
"key_value_store_address": "internal_keyvaluestore_tdx_2_1kzjd929eqlzd9n02uuj8jd48705vcrpvhv4mgxnaltrgystnca3qxk", | ||
"keys": [ | ||
{ | ||
"key_hex": "5c0c0131" | ||
} | ||
] | ||
} | ||
``` | ||
|
||
Will respond with data held under that key: | ||
|
||
``` | ||
{ | ||
... | ||
"key_value_store_address": "internal_keyvaluestore_tdx_2_1kzjd929eqlzd9n02uuj8jd48705vcrpvhv4mgxnaltrgystnca3qxk", | ||
"entries": [ | ||
{ | ||
"key": { | ||
"raw_hex": "5c0c0131", | ||
"programmatic_json": { | ||
"value": "1", | ||
"kind": "String" | ||
} | ||
}, | ||
"value": { | ||
"raw_hex": "5c90588c6d59227f64bd7fc68e38bf7c7013cf179a78d5562ce9378b1378e2fa", | ||
"programmatic_json": { | ||
"value": "internal_vault_tdx_2_1tzxx6kfz0ajt6l7x3cut7lrsz0830xnc64tze6fh3vfh3ch6587c5d", | ||
"kind": "Own", | ||
"type_name": "Vault" | ||
} | ||
}, | ||
"last_updated_at_state_version": 4939415, | ||
"is_locked": false | ||
} | ||
] | ||
} | ||
``` | ||
|
||
In our case, we may want to look up information about the vault (for example, the vault's resource address and balance). | ||
This can be done with the `/state/entity/details` endpoint. | ||
|
||
The gateway doesn't currently support iterating over keys, although we plan to add APIs which can support this in the near future. For now, a client would need to keep track on their own of all created keys or use lower level APIs to extract that data. | ||
#### Constructing json keys | ||
|
||
The json keys are specified as programmatic SBOR JSON (which is a recursive data format, with each layer being a discriminated union with the `kind` discriminator). Search for [SBOR on our docs site](https://docs.radixdlt.com) for more information on SBOR and the programmatic SBOR JSON format. | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor English article corrections: