what do you mean when you say lifetime?

certainly possible, you could also use Workers KV from your durable object if necessary

When is a DO disposed and how long can I keep it available?

are you talking about the in-memory state then, and not persistent storage?

I mean in persistent storage.

that's durable storage that is never deleted (unless you delete it)

Wouldn't you be concerned with users not disposing of them and them growing infinitely

I didn't see charges for storage only requests.

Seems like that could get out of hand.

that thought did enter my mind, just feels a bit hacky considering it's not the intended purpose of kv

not the intended purpose as in, using kv solely because it has higher storage limits

there's prices for reads, writes, deletes and storage: https://blog.cloudflare.com/durable-objects-open-beta/

I must have overlooked that. Thank you.

but also we will offer ways for you to iterate your objects, so you can clean them up if need be

so you could implement a TTL or something of your choosing

Great!

thanks for the info!

The iteration would be big as it would allow us to clear up the DOs and log the results in a seperate cron worker vs having to have the DO handle its own disposal.

that's fair, but KV is probably cheaper too, especially for larger objects. it may be a good fit unless you really need a transaction/consistent store

yeah it's top of our mind right now

something I should be working on as we speak 🙃

i mean... if you use DO as a sort of journaling system (?), it'd be consistent anyway right? or more like, if the DO is the only thing accessing it, it'll never be inconsistent since there's only one source of writes?

We're using DOs as a session handler for our app, and the controller, for a voice product, very interesting to see how it's gonna work out.

We also decided to use KV as a store for a voice recording, we were able to make a file store using it.

that's (mostly) true. what I meant was if you need to do transactions across multiple keys, or things like that

Big learning curve for us tho coming from dotnet and Azure Functions

hm.

i mean cheaper is nice and all, but half sure that'd come with a drastic increase in complexity which isn't exactly ideal

hey there, I was using the addEventhandler approach before switching to durable objects. Now I'm using the module based approach as I have to do when using DOs. It seams there is no location data on the request anymore - is this a problem on CF, intended or am I doing something wrong?

I think the best thing if you want to use KV as the actual data store you can add DO as a "middleman" to KV that will keep the data consistent. (I at least assume this would be the case). Basically on first request it would be: Req -> DO -> init from kv to memory -> update memory and kv -> end Then next requests would be: Req -> DO -> update memory and kv -> end Only potential problem I might see is whenever the DO gets evicted if another request comes in to re-instantiate the object and it reads an old value from KV.