So you wrap KV in itty-durable?
So you wrap KV in itty-durable?
WI just make my own midleware to handle the KV calls. Nothing fancy.
HSorry, I was misinterpreting "using KV with itty-durable" as "using itty-durable as an interface for KV". My mistake!
WI read that way…. Apear to be a reasonable trade off. But the behavior should be better documented.
WThat can also work, you just need to override the "persist" method.
KThat's correct. We try not to load two copies of the same script on the same machine, unless traffic levels actually require it.
AIs it possible to access the value passed to
idFromName()
JNope, just the hex id. You'll need to pass it down in your
fetchAlright, that's what I figured. Would be nice to have the option it in the future, but I don't see how it could be easily implemented :/
JYea it would be nice if it was available off of the
state
HCan you hard-code an id, if you don't want to regenerate it on every rerun?
HSo say for example I was using a DO as a global cache. I don't need to have more than one DO active at one time. Could I generate an id using a name, push it to the terminal, copy it down, and then hard-code it into my code?
ACalling
console.log(message)wrangler tailmessageDoes anyone else have this issue?
IProbably the KV store.
ISo you want to setup another durable object and list them in there in-memory? Because the storage of the durable object is basically a KV store right?
RHello, any news when Durable Objects will become GA?
IAh okay my bad didn't know that.
I@Deleted User I'm actually working on something similar now where I want to be able to receive a list of a certain type of durable objects
I@Deleted User What did you end op going with? I just wrote a little
StorageDurableObject
IIs this documented already somewhere?
WBrett can PM you the link, i dont know if i can share the same info. But im using the rest api to get list of DO objects, works well but is not "very fast"... depending of your requirements maybe just be simple to make you own list.
WThis same concept is also part of the nodejs module resolution. Thats nor pretty but i cant call that a antipattern considering the is very common and is the default resolution from the biggest js runtime out there. Anyway, you can just rename the output as part of your build step. Personally, im using the ESBuild bundle, so i just ask to output a .mjs file, but i can understand that other bundlers may need a rename. Anyway, i do think that request can be made on the wrangler github issues section, appear to be a simple adjustment.
KWe need to distinguish between the types somehow. The HTTP upload API allows each module's content-type to be specified explicitly. But, Wrangler needs some way to know what type each file is. For now, it uses the file extension to figure it out. However, you're welcome to propose a change to Wrangler that lets it figure out the file type some other way.