I dont really know how they work internally but I think its very fair to say that the object needs to be in memory for this conflict resolution to happen

I already do that, when i list my DO with 2GB data (not fit on memory) a can query that pretty quickly. You are speculating too much here... I can get a storage.list paginated and do my search. Thats already works!

what I would recommend is having either the KV or another durable object act as an index node, and put your indicies in it and use those as the basis of a search

the entire DO isnt going to be in memory, especially if its 2GB like you said

but the DO itself still has to be in memory so that it can perform conflict resolution.

unless that happens in the worker runtime itself,

I can ask around and see but even if its possible for this to be implemented, it probably will not be in the near future at least.

I would love to see a search myself, but from my experience and my understanding of durable objects its simply not what they are designed for.

maybe im totally off about this, so I would love to hear some input from someone else on the workers team.

Understood.... My problem relies in the fact the values of DO storage are limited to 32kb, so instead split a 10MB document (for example) in several key sections, i was trying to keep each one on a DO, and for a bonus a can support shared editing in parallel. But if the DO is not loaded in memory, i still want to know what inside then.

I do my search using the flexsearch and fit my needs.

i just create the index using the flexseach and a have a route /search and works nice.

I think you should just load it then

and use the standard ``fetch`` method on your durable object

you can have your worker query multiple at the same time

I think the limit is 50 sub-requests in a worker (im not sure if durable objects count against this limit)

you cant read the DO's state without it being ran in memory, but you can just call it and cloudflare will automatically move it into memory and evict it as necessary

I was planing to do that, but sounds inefficiently, but better try first how far i can get. If not works i will keep my currently implementation splitting my document in 32kb sections.

if it does not work you may want to look at macrometa or firebase or mongodb or something similar

as these have years of software engineering put into efficiency and design

Well... @User , looking again at my problem. If a spin up a DO to read/write a single KV entry (that can be 25MB) i still can use the DO to controll my editions and i probably can search using a regular work over the collections of keys.

theres nothing wrong with spinning up the DO

its still going to be fairly cheap

Any problem in use the KV storage inside the DO? Just to know if there's any know issue here.

no problem I dont think

but I haven't tested it yet

I think durable objects are the same runtime as regular workers so you should be able to do that okay.

any ideas why ``env.rooms`` is undefined?

the demo chat app uses ``rooms.newUnique()`` but this here uses ``OBJECT_NAMESPACE``