overall, testing of DOs seems really fragile...I get inconsistent errors, different errors on live r
overall, testing of DOs seems really fragile...I get inconsistent errors, different errors on live reload than hard restart etc
Can I enforce everyone in the United States to somehow use one specific D1 Database?This applies both to D1 and DO. If you want to use different databases per region, you can create a few of them, and then use your worker request location (in the request headers) to decide where to route your queries (choosing the database/DO that you want). Needs a bit of code, but doable.
I read that D1 performs replication geographically so this doesn't seem like a good fit. I would rather there be a delay than a client get the wrong or outdated data.Once D1 launches read replication you will still be able to get the latest data if needed, we will not break the default consistency. This would mean though that all your requests would need to reach the primary database (transparent to your code, we would do this for you probably), so you would basically use D1 as its current form forgoing the replication features.
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()
}