Yes. Ignore the Workers KV page when working with DO KV
Yes. Ignore the Workers KV page when working with DO KV
list() in DO KV returns the K:V pairs, whereas Workers KV only returns the key names (can Workers KV be changed to align with DO KV?? This is such a weird distinction between the two)
By writing a Durable Object class which inherits from the built-in type DurableObject, public methods on the Durable Objects class are exposed as RPC methods, which you can call using a DurableObjectStub from a Worker.
wrangler.yml and added a deleted_classes migration, but it still complained about worker binding not removed.this.state.acceptWebSocket(socket) instead of socket.accept() to avoid massive chargesstorage.put() multiple times without awaiting, it will group all the writes into a single round trip. If you put to the same key multiple times without awaiting, will it write to that key multiple times or will it only write the last one?env, you need to pass them in your RPC call to the DO.constructor, I might make an init method so I don't have to pass it on every call
init(uid) the first time the user object is created, save the user's id to storage, and this way it will be available in storage whenever I'm calling that DO again, right? Just need to set it in the constructor like this:Internal error in Durable Object storage write caused object to be reset.Network connection lost.

list()wrangler.ymldeleted_classes```this.state.acceptWebSocket(socket)socket.accept()storage.put()constructorconstructorinit(uid)Internal error in Durable Object storage write caused object to be reset.Network connection lost.app.get('/avatars', async c => {
const user = c.get('user')
c.env.uid = user.uid // is this a bad practice?
const userObjectId = c.env.USER_OBJECT.idFromName(user.uid)
const userObject = c.env.USER_OBJECT.get(userObjectId)
const avatars = await userObject.getAvatars()
return c.json(avatars)
})ctx.blockConcurrencyWhile(async () => {
this.uid = await ctx.storage.get('uid')
})