The issue though with exists is that it still would require a global lookup, even if you don’t manually do it

indeed, when the stub is returned, CF doesn't yet have the information that this DO id exists ? I ask because, may be another property of the stub like stub.exists = true/false could be useful 🙂

Maybe, but until you actually

fetch

the stub, it wouldn’t know whether it exists anyway

Because the database lookup doesn’t occur until first fetch

Yep, I've read it's on the 1st request that the DO is created. Too bad, so we really need to rely on another storage solution or to start all jurisdiction/worlwide DO to tests if exists

Thank you for theses clarifications @HardAtWork !

Would it work for you if it did the database lookup, but didn’t actually fetch the object?

yes, it's what I'm searching to tests, just to known if it's exists without a fetch() to the DO

I've just remember, there is a CF API to list all existing DO ! https://developers.cloudflare.com/api/operations/durable-objects-namespace-list-objects Do you believe it's a good practice to lookup inside ? ( May be it's more slow than opening/closing 2 differents DO jurisdiction, or even may be slower than get a KV cold key )

Not on every request, at the very least

If you can cache it, it would probably be best

Though yeah, you would then run into issues with update times

yes it's possible. Finally, I need to measuring if it's better to open 2 different jurisdiction DO (worldwide + eu) or if it's faster to still uses a cold KV key

That sounds truly excess. I'm using KV all over the place, and for cold keys I get a max delay of 2 secs, which includes the pipe latencies. And this is in India where the CF infra is not as extensive as in the western world. In fact, I always joke that its faster for retrieval from the origin DB (India to US) than from KV. Nevertheless, I've never ever seen anything above 5 secs, and thats extreme.

The main goal for us to uses CF is the 285 PoP, so we try our best to have the faster solution relaying on edge. DO are good for that, but the requirement for us to open 1 DO worldwide + 1 DO in EU jurisdiction, to start them (may be for nothing) just to known if the DO exists is not good. Also, managing KV with hashed email add extra complexity (lag of replication) and increase CPU time usage (hash algo). May be the best solution in our case is to replace KV and email hashed by a pre-created DO hosted in EU jurisdiction, with the goal to orchestrate any new DO ID. Something like env.GLOBAL_DO_IDS.fetch('/exists-do-id?email=') that return { id: 42, jurisdiction: 'eu' } and another env.GLOBAL_DO_IDS.fetch('/save-do-id?id=&email=') With this solution, this prevent to open 2 DO for just checking if they exists, and also prevent to uses KV (+hash)

Note too that DOs don’t spawn in most of the 285 colos, either way

Indeed, and when D1 will go out of alpha/beta, this could be interesting to uses it like a coordinator ( but in this case, it's require again to hash email because of GDPR, so wasting CPU time... excepted if D1 support one day a restricted replication area to the requested jurisdiction )

Using the DO to find the DO…

yep, could be weird, but it's save multiple opening of others DO/user for nothing... May be one day CF could implement a env.DO.exists(name) that is faster than opening a worldwide + eu DO with this name

Also, we don't need to relying on idFromName(email) anymore, so in the balance, this could also be better to just uses newUniqueId()

I've just noticed this sentence in the DO documentation about idFromName() : « After the object has been accessed the first time, location information will be cached around the world so that subsequent lookups can be faster. » Finally, this mean CF could check if there is a cached lookup for this id and give us this precious information ? Then we can do:

function isExistsDO(email) 
{
 let id = DO.idFromName(email)
 if (DO.idNameLookupInCache(id)) return true
 id = DO.jurisdiction('eu').idFromName(email)
 if (DO.idNameLookupInCache(id)) return true
 return false
}

Without requiring to open/instanciate/start the DO.

That cache is still pull-based, so if you’ve never asked for that DO before in a certain colo, it won’t be cached there

understood, good point !

humm I have a doubt, because they said « will be cached around the world », this suggest me it's copied in all colos. May be the documentation isn't enough precise and should say it's faster if requested from the same colo ?

@kenton or anyone who might know the answer to this... I understand that transactions were in DOs before Cloudflare introduced the automatic in-memory caching for storage and that transactions can slow you down, but I'm wondering if the introduction of the cache helps with transaction usage in addition to non-transaction usage. When the transaction finishes, do the writes from it go to the cache like non-transaction writes or do they use an older wait-until-it's-on-disk approach?

They go to cache, i.e. they behave like everything else in the new model. As always, the output gate prevents the rest of the world from receiving messages from your DO until the data has actually hit disk.

for a given signup, how do you determine whether it should be GDPR?

regarding the conversation about hashing, don't take legal advice from strangers on the internet, talk to an attorney if it's important to you. when you call idFromName('some@email.com') we do not store the variable length string 'some@email.com' in the record for the DO, we store the fixed length hex id. If you want to store the variable length name, you would have to explicitly store it yourself. for that reason, I would not expect hashing to have any impact on GDPR compliance one way or the other. that being said, there's nothing about a hash that inherently prevents it from being "any information which are related to an identified or identifiable natural person" so again, talk to an attorney

regarding the request for an interface to get a DO without creating it, I understand the ask, but in this particular case I'm not sure it meaningfully helps you

just saw a flurry of

Durable Object storage operation exceeded timeout which caused object to be reset.

even on simple reads in the NRT colo from 9.30am-10am US central, was there an outage there? Didn't see anything on status