transaction()? blockConcurrencyWhile has a different purpose than sync/async.
transaction()blockConcurrencyWhile
Bstorage.get/storage.set's implementations are sync, because applyMigration is async, .then puts continuation in the next event loop, so the log order will be before -> after -> initialized. I haven't tested it but unless DO has a different behavior to regular JS, that should be the case.this.someState is still undefined) by the end of current event loop. I don't know if DO is able to process messages in the same event loop as the one doing the construction, but if that's true, then that's an issue.
森森BblockConcurrencyWhile
L
this.someState = -1 before the call to ctx.blockConcurrencyWhile(...) and then the property won't be considered optional.BblockConcurrencyWhileapplyMigrations can just be sync.Bstorage.get/storage.set is async, you also couldn't do:await puts continuation in the next event loop, by which point transactionSync already exited.Ltransaction(...) which is async. Anyway, we seem to be going in circles 
Btransaction with SQLite?LWhen using the SQLite-backed storage engine, the txn object is obsolete. Any storage operations performed directly on the ctx.storage object, including SQL queries using ctx.storage.sql.exec(), will be considered part of the transaction.You can use both APIs, KV and SQL, inside an SQLite DO.
BtransactionSync with SQLite.森B森
HL森森HHH森
SL
transaction(...), so what you suggest could be done by starting one in one fetch/rpc call, but without awaiting the returned promise and just storing it in-memory. Then another request can await for it when needed.HLtransaction()Error: Durable Object test helpers can only be used with stubs pointing to objects defined within the same worker.
森
EE
1
state.storage.deleteAll() to remove an old instance. An old instance will not incur any request or duration charges if they aren't being accessed, but their used storage will be charged until deleted森L森
, does this mean the DO eventually will also have this feature11
Hibernation is only supported when a Durable Object acts as a WebSocket server. Currently, outgoing WebSockets cannot hibernate. on this page here: https://developers.cloudflare.com/durable-objects/best-practices/websockets/#websocket-hibernation-api1storage.get() and provide multiple keys, does each key count as a read unit, or do we count units per 4KB for all keys combined? Trying to minimise storage usage without moving to SQL backend森storage.getstorage.getstorage.setstorage.setapplyMigration.thenbeforeafterinitializedthis.someStateundefinedthis.someState = -1ctx.blockConcurrencyWhile(...)applyMigrationsawaittransactionSynctransactionSynctransaction(...)transaction(...)transactionfunction doX() {
this.promiseTxn = this.storage.transaction(async (txn) => {
const a = txn.get("keyA");
const nextRequestValue = await this.waitForAValueSetByAFutureRequest();
txn.put("keyB", a + nextRequestValue);
});
}state.storage.deleteAll()Hibernation is only supported when a Durable Object acts as a WebSocket server. Currently, outgoing WebSockets cannot hibernate.storage.get()async function applyMigrations(storage: DurableObjectStorage) {
await storage.get(...)
// Do migration stuffs
await storage.set(...)
}class MyDO extends DurableObject {
someState!: number
constructor(ctx: DurableObjectState, env: Env) {
super(ctx, env)
console.log('before')
applyMigrations(ctx.storage).then(() => {
this.someState = 42
console.log('initialized')
})
console.log('after')
}
}async function applyMigrations(storage: DurableObjectStorage) {
storage.transactionSync(async () => {
const currentMigration = await storage.get(...)
// Do migration stuffs
await storage.set(...)
})
}// Using KV for simplicity
const a = txn.get("foo")txn.put("bar", a + "yo");miniflare: {
workers: [
{
name: "dummy-do",
modules: true,
scriptPath: "./test/database/mo.ts"
}
],
durableObjects: {
"MockSqlBackupDO": { className: "DummyDO", scriptName: "dummy-do", useSQLite: true }
}
}