I guess I'd put it this way - columnar databases are optimal for a variety of use cases for data storage and retrieval. json files (which can be seamlessly mapped to objects with existing tools) also are good for a variety of purposes and situations, some of which overlap with columnar databases. I am beginning to get a sense of the optimal use cases for DO and KV, which are somewhat different but also have overlap. They are clearly not optimal for my use case. Which I knew going in. But I was open to the idea of doing something on the edge even if weren't optimal. But unfortunately it is clear to me that the usage of DO and KV is so new that almost no patterns exist to model after and I have to solve everything myself, of course with input here in the discord. I don't mean this to be a dig, it's the reality. Some devs like the challenge of this. Some use cases really are optimal - for instance DO solves a lot of the state issues with messaging. Some people are willing to spend more time just to be serverless. These are all great reasons to use it. I just unfortunately don't fit into those categories. In some ways, I'm the opposite, because I don't just want things to work, I want to use patterns that fit with my experience of best practices to prevent regretting it later. For instance, I would never parse the url like the sample app, even in sample code. I wouldn't pass body info to fetch via a header or querystring because those are not best practices generally. Every one of these deviations from the samples requires more work for me to figure out how to do it the way I want things done. In any case, I'll still be working with Workers!

Hi! We want to move from a old database of N users to 1 DO per user, close to each user. For technical reason, this could be better for us if we can assign right now a newUniqueId() in our current DB, and the next time they sign-in, to uses this ID to connect to the DO for the 1st time, do the 1st fetch(). My question is, is it a problem to generate thousand of newUniqueId() but uses them later without doing any real DO creation? (could be in months for some users) thanks

Why do you even need to generate the ID beforehand? Why not just generate it when they log in, and then add the ID to wherever you store it?

You don't want to do this because newUniqueId encodes the nearest colo. It'd be better to either lazily call newUniqueId from the eyeball location the user hits or to just (lazily) use idFromName with some internal ID you have

Humm but why the locationHint is a parameter of the .get() function in this case?

It's more convenient for technical reasons, without going to deeply in the subject, I have a kind of aggregator of each mini-DO, with some rights to update/delete, dependant of the original DO id

locationHint will relocate a newUniqueId if it hasn't been created yet, so if you plan to use that then it could work, although I don't see much advantage vs just lazily using idFromName with some external ID

Ok, so I keep in mind it's not the best/fast option if this need relocation

Oh I've just realized I haven't read your answer carefully. You said « if it hasn't been created yet ». So, as said before, my goal is only to generate newUniqueId ( without being attached to any place, excepted if I uses subdomain for jurisdiction ) I'll not uses the .get() function to get the stub, so in theory they will not be created. If I generate thousand of newUniqueId() from a Paris worker now (without requesting a stub), can you confirm if later (may be months after), if a uses this previously generated Id, from a worker in NY, then the stub will create the DO closes to NY ?

It will not, you'd have to use

{locationHint: 'enam'}

and then it would be a random colo in ENAM

Ok, thank you for theses precisions

It seems like you'd trying to tie two DBs together? If so I'd use

idFromName(primaryKeyFromYourSQLDB)

or something

And only when the user requests it

it's a good idea yes!

I wanted to prevent to uses the world lookup of idFromName() but it's surely the best option in my case, thank you

If you want to use newUniqueId you'll have to do it lazily when the user asks for it, then you'll have to find a way to get that ID back into your other DB, which it sounds like you're trying to avoid

When DOs are "generally relocatable" this all won't be an issue, but there is no timeline for that yet

yes, this will be really useful ! ( even for case scenario of jurisdiction, imagine someone from US starts to live in EU, we're forced with GDPR to own his data in EU )

Is there any plan to allow creation of DOs via the CF APIs? AFAICS, there is only GET right now (https://developers.cloudflare.com/api/operations/durable-objects-namespace-list-objects)

Transactional storage's

put

and

delete

functions support up to 128 keys at a time. But what if I loop over them without using await over 128 times (taking advantage of automatic write coalescing). Is that going to run into the same limit?

Do I need to await at least once every 128 operations?

I'm starting a new publication on Cloudflare Durable Objects Design Patterns. I'd love input (good, bad, or ugly) from the folks here on the content to keep improving it. https://medium.com/cloudflare-durable-objects-design-patterns

Cool idea 👍 ! I recommend checking out

do-transactional-outbox

for an even stronger model of storage consistency. For your example in the blog post, I'm not sure if by using

await

 you potentially eliminate (some of) the benefits of caching state in memory, let me explain. I recommend taking a look at `state.blockConcurrencyWhile`: call it in your constructor, no need to await it (you couldn't anyways, since constructors have to be sync), but it blocks further requests until you finish with your

hydrate

function. Then, you can always be sure that

this.name

and others will have been populated whenever your request comes in via

fetch

, so you can simplify your code further - eliminating another potential concurrency issue, where you're awaiting the hydrate promise, and another event handler starts executing, calling hydrate again, and potentially reading from storage once more as this.hydrated may not have been set to true yet (knock knock, race condition, who's there type situation), and then you overwrite name from the second call. Basically, use

blockConcurrencyWhile

in the constructor, move

hydrate

to within that call and remove it from

fetch

. Oh, small note, you could reduce boilerplate by exporting a function instead of a class, which applies the argument as the static class and returns that as the DO class for the runtime

Are you able to use a

ctx.waitUntil

with durable objects? I don't see any way to get the execution context from the fetch handler in a DO (it's undefined) (plz ping)

Afaik, there's no need for it in DOs, they'll keep running until all promises have resolved

So I just launch a promise then respond with return and all is good?

Yep

And that won't block the response?

If you await it, it will

But otherwise it'll just run asynchronously