The idea is that in the future we could (will?) start respecting that hint, even if the object existed already.

Oh also, little Quality of Life thing, could there be a way for a DO to inherently know where it is? It’s fine if it changes because it is moved, but just that it knows without having to do a trace would be awesome

It's certainly possible. Whether we'll actually do it... I don't know yet. Are you thinking airport code? Or like the equivalent locationHint? Or?

Airport code at the minimum, locationHint could be inferred(though might be cool to have it too). Also, maybe numeric colo/metal ID for Ent(for metrics, to see how many DOs are moved are on one metal at a time).

Going back up to what I said earlier, if

idFromName

supported Jurisdictons, would it confuse anyone that these IDs point to three different objects?

NS.idFromName("foo")

NS.idFromName("foo", {jurisdiction:"eu"})

NS.idFromName("foo", {jurisdiction:"bar"})

And regardless of whether it'd confuse you, do you have a different idea for the API you'd prefer?

I feel like that would be confusing indeed

, that would be very confusing. I can't think of a better API that could work here though

realistically I think names should be unique and trying to change the jurisdiction value shouldnt be allowed and if set to something different should throw an error

(as in if you have

NS.idFromName("foo", {jurisdiction:"eu"})

doing

NS.idFromName("foo", {jurisdiction:"bar"})

should throw)

could have a "quiet" option to not throw the error and just send it to the existing one too?

Hm, quiet seems like a dangerous thing to pair with jurisdictions, since you'd typically use these to deal with legal compliance.

That's fair

That said, throwing if the same name is used in another Jurisdiction likely isn't going to work in our system anyway. Or it'd be too slow, at least.

The only other real option on the table is to require you make a namespace per Jurisdiction, and then you'd have to manage them yourself in Wrangler

And choose which binding to call

.idFromName

and

.get

on

That, or we could force you to use a weird method to try and make it more obvious that the objects are different

NS.idFromName("foo")

NS.idFromNameWithFlags("foo", {jurisdiction:"eu"})

NS.idFromNameWithFlags("foo", {jurisdiction:"bar"})

js
NS.idFromOptions({ name: 'foo' })
NS.idFromOptions({ name: 'foo', jurisdiction: 'eu' })
NS.idFromOptions({ name: 'foo', jurisdiction: 'na' })

Would be less confusion imo, it makes intuitive sense that these are different option objects and thus the ids returned are different and unrelated too.

Yeah, interesting

as long as it's well documented (warning could be a good idea) - lgtm

I really like this one. It makes it much more clear than having a separate name and options thing does.

How about

NS.jurisdiction("eu").idFromName("foo")

ooh I'm a fan of that

it distintly namespaces the DO under that durisdiction

I think there is a small difference in confusion between

NS.idFromOptions({ name: 'foo' })

and

NS.idFromOptions({ name: 'foo', jurisdiction: 'eu' })

being different objects than

NS.idFromOptions({ name: 'foo', jurisdiction: 'eu' })

and

NS.idFromOptions({ name: 'foo', jurisdiction: 'na' })

being different.

As in, that if you explicitly specify two different jurisdictions it is more clear they are different than between one where you don't specify one and one where you do. So maybe all we need is a way to "enforce jurisdictions" on a namespace. But then you get into the issues of we don't have jurisdictions for everything, so you probably need a "other" one.. Certainly a non-trivial thing to get right. Long story short, I think your

NS.jurisdiction("eu").idFromName("foo")

is probably the best solution I have seen so far?

I don't use DOs but after lurking here, I also think the

NS.jurisdiction("eu").idFromName("foo")

is the most clear

Agreed. Would also be helpful if you could store the "jurisdiction" part and reuse, i.e:

js
const eu = NS.jusrisdiction("eu");
const do1 = eu.idFromName("do1");
const do2 = eu.idFromName("do2");
const do3 = eu.idFromName("do3");

That's the idea, including

.get

, so

eu.get(euId).fetch(...)

works but

eu.get(otherJurisdictionId)

would throw

Is there any way to manually generate an ID String without a Worker?

Hm can you elaborate?