(then again, "dying properly" is also on my wishlist, it would require "close all websockets cleanly" so the client is informed immediately, so it can reconnect with just a minor glitch)

Yes, correct websocket status is a problem throughout. That's beta for you, although I don't get the impression they're planning on fixing zombie sockets

😞

I think its safe to say that ``setTimeout`` is blocked for durable objects and workers?

It works, just the limit on # of `setTimeout`s doesn't play nicely with long-lived DOs at the moment -- we're planning to resolve that

oh okay great 😄

I still see a case for a centralized game server.

but anyways, glad to hear its being fixed.

Any plan to get the underlying storage of all durables of a particular class without create each one? If a have a class document for example, if a want o search though all of then will be nice to do that without call each durable individually.

well each durable has to be spun up if its been evicted from memory

durable objects weren't meant to be searched

if you need search you should use macrometa or firebase or something, its why cloudflare partnered with macrometa.

Search is very complicated and durables are not really intended for that use case.

Perhaps you could build a database ontop of durables that permits searching, but you would have to build and distribute the indices accordingly.

Hi! just a quick question: when/under what circumstances is a Durable Object evicted from memory?

Hey all - I'm planning to use DO's strictly as a caching layer - since I can't move my Postgres instance to the cloud/edge yet. To that end - does a durable object have a TTL (time to live) so that it self-deletes, like a KV pair does (I believe)?

Hi everyone! Has anyone experieced their durable object data doesn't persist after a couple of minutes?

I think this make no sense... Several examples with DO that Cloudflare provided is a very fine grained object that can be instantiated hundreds of thousands times; The announcement blog post por example use a "User" as DO class, and for sure you need to keep track of you users and at some point search then. I understand theres no api for that yet, but the "storage" of each object is the only thing that live forever. Today we can search the KV storage, but on DO we can only list inside of the DO itself. And thats make complicated to make a fine grained object;

As @User said on the Hacker News: "For Durable Objects, applications should aim to make their objects as fine-grained as they reasonably can, so that the limits on one object are not likely to matter. Meanwhile, the total capacity across all objects is effectively unlimited." -> https://news.ycombinator.com/item?id=24616169

yes

you should have many objects

objects dont have much overhead

but reading thousands of them would

thats just not efficient to spin them all up just to search

thats why theres document databases for example

because there is an efficiency in centralizing indicies and indexes

But about search on documents itself be a hard problem, i usually use this on my JS projects: https://github.com/nextapps-de/flexsearch Works better than severall full text search implementation in may databases.

> However, some use cases aren’t easily implemented with Workers KV or Durable Objects. Think querying complex datasets, or communicating with an existing system-of-record. Even if we built this functionality ourselves, there will always be customers who want to use a different tool for data storage and access.