Well if you try to do more writes now, does it fail?
Well if you try to do more writes now, does it fail?
SYes
ESo it sounds like you bypassed it by doing them in bulk and the system was too busy bulk writing to think to check to the limit
SLmfaoo
ESimilar to a race condition
SSo bug bounty?
EI mean, maybe
EIt wouldn't be a very high priority one, but it definitely is unintentional behaviour
Swhat would the CWE be tho 
E¯\_(ツ)_/¯
E@benycodes.. if you want to do any filtering, the best to do that in key value stores is by prefixing keys.. so that you can list a subset
BI thought so. I guess kv is not the best thing for being used as a database that needs querying
EIt is, but it requires a very different way to model your data.
EIn relational databases you model your data based on you write/storage needs, where in key-value stores you store your data based on query needs.
HAdd the KV Namespace ID to your
wrangler.tomlIf you don't care that you will be interacting with your production namespace, then set the same ID for both
idpreview_id.
EWhat limits are you concerned about?
EAhh.. your daily limit you mean?
JCorrect, every time you write to the key and include the
expirationTtl, it will extend the ttl. So if I write to a key with expirationTtl set to 2 hours, wait 1 hour, then write to it again with the same ttl, then the expiration will be bumped to 2 hours from now
BWith the eventual consistency caveat of KV, does that mean it's impossible to do "append" operations with them?
EYeah, pretty much. If one worker tried to append then it may be reading stale data and then another worker in a different location also tried to append and suddenly your count is completely wrong.
For counting or appending things reliably and consistently I believe #durable-objects are best suited
For counting or appending things reliably and consistently I believe #durable-objects are best suited
BBut durable objects are being charged for its lifetime, no?
BI'm thinking doing a like system similar to most social media sites (users can like a content, and users can see how many likes a content has) and I'm feeling maybe serverless is not the way to go.
Eim gonna go ahead and repost this here, it was incorrectly flagged
Ethough half of it is still missing i think
BTrue, serverless was the wrong word there.
BI'm not very good at backend or infrastructural stuffs, and my project does have global presence
BThere are DBaaS with global replications, but I'm also trying to see if I could work CF into what I need.
AYou would only be charged whilst they are doing things. So, in your case, the few milliseconds needed to add or retrieve a comment. It's only when you are using we sockets that they run all of the time
BI wasn't aware, that changes things.
BWhat are you guys thoughts regarding this (implementing a content like system with CF KV/durable objects, instead of a database)?
BI figure there should be far more reads (viewing a content) than writes (liking/unliking a content) and can benefit from global fast delivery, so CF KV seems like a natural good fit.