and it is a good idea the cache the DO's id (store on client via JWT) or just get the DO via the use
and it is a good idea the cache the DO's id (store on client via JWT) or just get the DO via the user id everytime instead?
idFromName has one extra hop the first time you query it but then it's cached in cloudflare's datacenters, so assuming you have regular requests, there shoudn't be a performance benefit caching the DO ID yourself./user/{userid}, would it be better if we first look up D1 to see if the user id exists, or directly get the user's DO via idFromName(), and see if it was previously initialized, destroy it (via deleteAll()) if not?and see if it was previously initialized, destroy it (via deleteAll()) if not?Why would you need to delete all if nothing has been initialized?
SELECT * FROM 'tablename' and we know the DO is not initialized if the table name doesn't exist? (or querying sqlite_master to check if table exists)init() call that is part of a resource creation flow. Including any initial SQL table creation and setup. After the init() completes, any other SQL migration is done only when necessary (at the point of access, not the constructor, and it's very fast/noop majority of the time when done properly: https://github.com/lambrospetrou/durable-utils?tab=readme-ov-file#sqlite-schema-migrations ).Does it ask every data center if that name id has existed before creating the object? or does it create it first anyways, and only sync at storage level?This is my personal suggestion, but you shouldn't design your applications based on internal implementation.
If it was the latter, if two people decides to create the same name id DO at the same time on the opposite side of the earth, they would not see the same in memory status as the other? (or is there more memory syncing magic involved)Read https://developers.cloudflare.com/durable-objects/platform/known-issues/
ws can be found in the this.state.getWebSockets() settransaction can be used over transactionSync even in SQLite DO, does that mean the purpose of transactionSync is merely to provide a sync API?getWebSockets(), but your code proves it always would be for the server to respond. Interesting issue durable_objects.namespaces.objects API always returns hasStoredData: false for SQL-backed DOs, even if they do have data. Is this intentional or a bug?alarm(), so whatever happens within the alarm() doesn't really affect how the original alarm() is invoked


webSocketMessage(source: WebSocket, data: string) {
for (let ws of this.ctx.getWebSockets()) {
if (ws == source) {
continue
}
ws.send(data)
}
}async alarm() {
await setAlarm(someTimestampFarIntoTheFuture)
await somethingThatWillFail()
}durable_objects.namespaces.objectshasStoredData: falsealarm()alarm()alarm()