idFromName()

always returns instantly. It computes the ID using an algorithm. There's no need to do any network I/O. So there's no performance difference between using

idFromName()

vs.

idFromString()

(which takes the raw hex ID). With all that said,

newUniqueId()

produces IDs that are faster to look up than those produced by

idFromName()

.

(The reason for the performance difference is because

idFromName()

needs to check whether the same name is used anywhere else in the world.

newUniqueId()

doesn't need to do any such check because it knows what it returns is unique.)

Sounds very (walltime) expensive like a 500ms global lock?

Il try to start using the internal id

It doesn't require a global lock, but it does require choosing one location in the world to be the "source of truth" about where that object lives, and if you're unlucky the chosen location might be on the other side of the world.

but it'll then be cached so it really only affects the first request

Like I could do idFromName, then inside the DO do state.id.tostring, then do idfromstring on another DO, to get back to the named one?

Hum

Sure but that doesn't accomplish anything vs. just using the name everywhere.

to be clear, the difference in behavior is encoded into the ID itself. The system knows the difference between an ID originally created using

idFromName()

vs. one created using

newUniqueId()

as long as the idFromName id WONT change if the DO shutsdown and starts again (but has same name) il be good

that's correct, it never changes

to be clear

javascript
  let id = env.USER.idFromName("username:bob")
  let obj = env.USER.get(id)
  return obj.fetch(request.url, init);
// inside USER bob DO
   internal_id = state.id.toString()
   let id = env.RING.idFromName("north_america")
   let obj = env.RING.get(id)
   return obj.fetch(request.url, {internal_id: internal_id});
// inside RING do
   env.USER.idFromString(internal_id_we_got_from_USER)
    ..

assuming USER bob DO and RING do can restart multiple times

and RING should not lose the mapping (stores it in storage API)

env.USER.idFromName("username:bob")

will always return exactly the same value forever, regardless of whether the object is running or even exists.

that id == to state.id inside the DO?

(however, the same name for a different class will produce a different ID)

yes

perfect then, i could even store the state.id as state.id for 1 less operation right (into Storage API)? i dont need to toString() it?

I think you do need to

toString()

it

only toString for sending it over the fetch

and then you'd use

idFromString(stringifiedId)

to parse it

kk il keep it as string just incase

actually itl be easy to test

we might fix that sometime, it just requires that we extend the "structured clone" serialization mechanism to support the ID type

not a big deal tbh. so far liking DOs, my biggest pain point is debugging whats going on but made a few utility funcs (since I have a tick inside 1 of my DOs, that processes work indirectly on all the connected websockets, just made it broadcast a msg to all if it throws)

it originally was

./index.mjs

but I played I added ./dist to test if that was the cause but no. I just got it working... by adding the

--new-class LogTopic

switch.... that's a pretty misleading error - sure it used to be different and more specific if you didn't have that switch and hadn't previously deployed the class.

is there a way to set some kind of expiry on a durable object?

something like expiry for kv, except that i need that strong consistency