so your approach is to have a db lookup first then to invoke a DO?
so your approach is to have a db lookup first then to invoke a DO?
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


/studio to the deployed instance URL.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()
}