Can KV do conditional writes and/or transactions?
Can KV do conditional writes and/or transactions?
HIt cannot
JAPI and/or paginated Worker is really your only way today. You'll just have to slowly iterate through keys to avoid hitting any limits and such
MI added opentelemetry tracing and can see that when I do lots of parallel reads/writes with KV (25+), I'm hitting the 6 concurrent connections limit. Something I was hoping would take ~250ms is taking about 1.2s+. I wonder if perhaps I am using the wrong solution? My origin is returning multiple entities that I want to cache in KV separately
PHello! I'm curious if there is a way to delete all of the keys in a KV namespace at once? Similar to FLUSHDB in redis? I know there is a batch process where you select multiple keys at once an delete them but I was wondering if there was a way to do this in one command without recreating the namespace.
Thanks!
Thanks!
UOne more feature I forgot about that would be nice:
- Reverse listing items
Will make it so I can sort date based ids how I want them
HKV doesn’t currently support that
Poh I see, so the only current option is to pull all of the keys and delete them?
Mwhen running workers-rs with wrangler on local mode, my code attempts to store a value on the key value database, (no errors), but when i check the dashboard on cloudflare, there doesn't seem to actually be anything stored
Manyone know why?
CLocal mode doesn’t effect any remote resources
Mah i see
Mso if i use on my worker with local mode enabled and attempt to add something, it'll just be stored somewhere locally on my system?
COnly if you have the persist flag (wrangler 2). Otherwise it is stored in memory and is gone once dev stops
Malright, thank you
BDoes KV support secondary indexes?
INo.
IYou can list keys by prefix but that's it.
BThanks!
BSo to "resort" something I'd have to delete and readd it with a new key right? @Isaac McFadyen | YYZ01
IYeah pretty much.
BCoolio
IKeep in mind that because KV is eventually consistent if you read a value then change the value with the same key it might take up to 60s to see the new value in other locations
IIf you change the key, as long as you haven't queried the key before, it should be instant.
IIf you've queried the key before, even if it didn't exist at the time, it may take up to 60s to see the new value
BHuh... Nah, this key will have been queried before 
IIn which case, yeah, 60s (or more in very rare cases) to see in other locations.
BIt'll be queried and then immediately updated again
BFair enough, thanks!
B@Isaac McFadyen | YYZ01 do you know if there's a way to count keys? Something like the
list()I don't believe so, no, aside from just manually calling
listI'll have to do that then. I know that there's eventual consistency involved, but I'll need a count even if it's a rough count
IlistEasy way to test, actually - if you call
listI am wrong, just tested and KV 
listSorry about that.
BNp, thanks for checking!
BThat's more a question for the wrangler channel I think.
BThey get cached for the exact same sets of parameters. The cache key is built from the parameters (prefix, limit, or cursor) and cached for max 1 minute (IIRC you can't customize the cache TTL currently).
BDo you know if 
listcursorthe latency on these kv gets/puts seems awfully high no?
BIt shouldn’t. If you’re doing writes concurrently then it’s possible you cached the end of the list and need to wait a minute or so. What’s your namespace?
BWhich geographic location is this happening in and are you sure the gets are happening on a key that’s supposed to be already cached? Also is this a change in behavior or a new measurement you’re looking at
MMy bad, I thought Region: Earth meant all the data was replicated globally? I’m in Australia so if both reads and writes are going somewhere off-continent that would explain these figures