Beware expiration is from when you write. It does not refresh on read. So a key can be read a lot an
Beware expiration is from when you write. It does not refresh on read. So a key can be read a lot and still expire once the TTL is over.
ACould you please share a screenshot of what you mean by this?
BAre you saying because it's got a black background in the dark theme? Or because it's non-obvious that it's editable?
BIs there a way to list keys from KV in reverse?
BAs far as I understand it, KV orders keys in ascending order lexicographically righ?
BIs there a way to get the "top 10" keys or something?
UNot currently sadly 
BAh, okay. I'll have to store my keys in reverse then
U#durable-objects do support reverse sort and you could add cache api on top of DOs which would make it somewhat close to KV
BThanks
BSo I have a problem, I write data to KV (via a CF worker), then in another request (to a CF worker) I
listgetgetnullgetwhilegetnull
JThis is really by design with the way that KV's eventual consistency model works: https://developers.cloudflare.com/workers/learning/how-kv-works/
JYou could do a
whileThanks!
UThat is interesting that the list shows it though on first get it shouldn’t be cached. Unless you tried to do a get before the list then get 
BYeah, Idk what's going on
BWhat I've decided to do was store the creation date in the key metadata, and wait 60 seconds after it's created (if I'm trying to get the value before that time)
BI tried using lower values like 30 seconds, etc, but I was still getting nulls. It seems like 60 seconds is how long I should wait before I can confidently not get a null value
WConsistently as in like 100% of the time or?
WThat's fun.. all keys?
Is that namespace enrolled into kv2?
Is that namespace enrolled into kv2?
WInteresting - @robsutter @beelzabub if either of you are around
WSent a message internally
WCan you send some of the key names?
UYou wouldnt store JWTs so im confused what you would be using KV for in that sense
BYou’d use KV to store the tokens that would be used to validate the JWT. That’s what Cloudflare’s edge auth did for a while and may again at some point in the future
BD1 is for when you want consistency / doing more complex queries. If you can deal with eventual consistency and your queries fit a key/value mapping, KV is going to probably work better for you from a performance perspective (10s of Ms vs 100s for D1). You can of course add a cache in front of D1 with some work to try to bridge the gap but there’s not yet a way to leverage the caching layer that KV uses for other use cases (looking to make this available)
HYes
SWould a single key be a good way to store all the data for a single user profile? You have to update the whole value each time you update any of the data right?
HUse a single key, but run updates through a Durable Object, to ensure simultaneous writes don’t break anything
