is there a way to generate DO types so that workers that dont define the DO can take advantage of ty
is there a way to generate DO types so that workers that dont define the DO can take advantage of type hints in the ide?
Could not serialize object of type "DurableObject"
RpcTarget class will need to proxy function calls to required stub. In your example, BarRpcTarget needs to extend RpcTarget, and its constructor() should add the required stub which was already pulledby the instanced Worker, and also have class methods that will essentially call this.stub.func() on the actual DO stub. Screenshot is an example of my implementation for RpcTarget

adding this global ordering type of logic on a class which extends this classNot sure if extending is the right thing, I usually prefer composition, so another class using the sharding abstraction as its storage layer and for localized queries. The outer class is mostly to orchestrate which shards to query and do potential aggregations if needed.
do you ever see a future possibility of making the # of shards dynamic? AKA scaling storage practically infinitely?Absolutely. It's in my plans, but I want to find a nice API for it first. Dynamic shards need splitting and merging shards over time, so ideally we should provide some DO native hooks for it. Until those are built and published I want to experiment doing it ontop but needs some time.
getRpcTarget() on your DO, and calling it from a Worker allows you to pass around that returned value and anyone calling it will go back to the DO.Indexes will add an additional written row when writes include the indexed column, as there are two rows written: one to the table itself, and one to the index.
list({prefix: 'pre-')list() order is always lexicographical and there's no way to limit the list, but there's also https://developers.cloudflare.com/durable-objects/api/storage-api/#list which includes options such as limit and reverse ...can these all be used together with list({prefix: 'pre-') from the KV API?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 charges[[durable_objects.bindings]]
# This is the name of the binding that will be availble in our worker
name = "CHATROOM"
class_name = "Chatroom"wrangler.ymldeleted_classes```this.state.acceptWebSocket(socket)socket.accept()