I see. So the

alarm()

function should have access to any variable on the DO? And there's nothing stopping the

alarm()

function from calling the DO over http? (although it doesn't make much sense if it has access to variables)

It should, yes. There shouldn't be any restrictions in calling itself on the

fetch

, but if a variable isn't defined in the

alarm

, then it probably won't be defined in the

fetch

either, unless it is implicitly created.

Alright. I'll debug a bit more. Thank you for your input 👍

curious, has there been any progress on this? this is a major annoyance for our workload 🙏

Hello, I'm wondering if its possible to tell which data center a DO is currently running. From what I'm seeing in my logs I believe that IncomingRequestCFProperties#colo is the data center where the request enters CloudFlare's network, and not necessarily where the DO is running. https://developers.cloudflare.com/workers/runtime-apis/request/#incomingrequestcfproperties

Yeah that will be the request it came from not the DO colo. Right now it is possible to do /cdn-cgi/trace, but there has been a discussion about that being removed so it wont be possible to tell.

Hey guys. So considering that DO persistent storage is a kv storage system, it makes it kind of limited in applications we can use it for. I was wondering how you guys get around that? Like say I am creating an e-commerce order system. Would I just create an array to store all of the ids of the unfulfilled orders? I could see that getting real ugly real quick in my head? I just need some capabilities past simply retrieve an object by id?

You could have a set of keys named

unfulfilled:<id>

, then you can list unfulfilled orders by doing a

list()

operation with

prefix: "unfulfilled:"

.

Oh that’s interesting. Researching it. How many ids could it store before I have to worry about 500ms+ slowdowns

Lots. It should perform similarly to if you had a database with a table and you were SELECTing from the table.

of course, it's less convenient than a SQL database in that you have to maintain your "indexes" manually by creating a separate range of keys that you can query like this.

We have some ideas in the works for making this better.

So is the list method available in durable objects persistent storage or only on kv

Anyway I can see an example somewhere?

I'm talking about Durable Objects storage here, which has a key/value interface. Workers KV is totally different.

Yeah that’s what I’m interested In DO persistent storage

Here’s my situation: I have data like ex orders. For these orders I have a requirement where I have multiple clients even across the world (not required by preferred) mutating it at the same time. I thought early in the lifecycle store the orders in DO to get the strong consistency and then when order is closed delete from DO and store in sql database

Not sure about a good example. The chat demo only stores one "table" in its storage: message logs, keyed by timestamp. So it doesn't need prefixes. But here's where it performs a list(): https://github.com/cloudflare/workers-chat-demo/blob/master/src/chat.mjs#L295

So do you think this list method is a good approach to get a little more capabilities then just kv query. Do you think it should be sufficient for my use case where the most open orders per DO storage is maybe 500-1000 at most

yes, listing 1000 items should be no problem

Okay do you think it’s a decent approach to delete the orders every night on DO and migrate them to a sql database

I guess I don't know enough about your app to evaluate that

could be a fine solution depending on the problem

Basically the orders are only really used the day they are created. But maybe 10 days in future customer wants to see his order. We could then just retrieve it from sql database. Basically I’m using DO storage to allow strong consistency the day order is created since multiple clients will mutate simultaneously. But then after that day no collaboration on mutations needed at most maybe one person will mutate something in order like give refund.

Do you think 3 people working on the same order simultaneously across the world will have a good experience if the order is stored in durable objects persistent storage? Or would it need to be in the memory to get real time experience

Workers KV also has a list with prefix query pattern. I'm using it in both KV and DO.

It does, but it's more limited: It only lists in forward order, it's relatively slow, and it doesn't return values. Workers KV's list() is intended to be a less-used operation whereas with DO it's expected that list() is how you do queries all the time.

I've tried hunting in here and through the docs but I don't think I'm finding my exact answers. If I make a change to a DO that is published (modifying methods), do I then need to run a migration or are migrations only for data changes that occur?

and if a migration needs to be made to the same DO class like that, how would i make the migration using wrangler.toml? would it be a rename?

JK, I think I found it can anyone confirm that this still applies? https://discord.com/channels/595317990191398933/773219443911819284/1012363908562030632