That's a per value limit not a total limit. You can have an unlimited number of values per object

oh I see...

interesting

a lot of other alternatives also offers to display top 10 voters per poll. I made some calculations and if I want to store username + amount of votes then DO will only be able to handle around 8000 usernames. Example if I store in DOs:

json
{
  "Username1": 3,
  "Username2": 12
}

one solution would be to have a limit for example 100 and as soon as 101 person vote it will remove the one with the least votes from object.

but this won't work if for example 500+ people vote in the same day.

So it would remove the ones that still have 1 month left to do to vote and maybe beat others and enter the top 100 voters.

but storing each username under the different key would just be a pain as I would need to read thousands of keys just to get usernames that have the most votes.

not really you just store their number of votes in the key so that they can be listed in the order of most votes first

wou list actually return the values.

yes

Feels nice that all problems just disappeared in a second.

When we talk from DO-A to another DO-B, is there any advantage if we initialize the stub once during the DO instance creation (or during re-instantiation) in the constructor? Of course, I'd retry if fetches fail. But I'd like to think connecting from a DO to another DO has this advantage compared to connecting from a worker to a DO (where each worker request would need to instantiate the stub every time)

is there any way to delete all durable object storage?

like across all durable objects in a given namespace

Not without deleting the namespace

i see, and deleting the namespace also deletes all objects in it?

Yes

got it, thanks.

another question — is the workers.dev domain suitable for production use?

the 'dev' tld makes me think it's only for development

can't find any documentation about it

it can be but generally you should always use custom domains for more control

for sure

i'm trying to wrap my head around how i'm going to manage the # of DO instances i'm going to have...

i'm gonna have tens of thousands

and there's no clear way to manage them

generally speaking you'll need to iterate through DOs using https://developers.cloudflare.com/api/operations/durable-objects-namespace-list-objects

can you say more about what management operations you'd be doing besides deletion?

sure, my use-case is i'm use DOs to serve as the gameservers for an online web game i'm building. i don't really need persistence, just stateful routing to on-demand compute over websockets. 1 DO = 1 "room" for the game. a room only lasts a few minutes, and then once everyone disconnects, i don't want it around — i actually want to recycle the room ID.