search

yjs / y-indexeddb

IndexedDB database adapter for Yjs
https://docs.yjs.dev/ecosystem/database-provider/y-indexeddb
Other
196 stars 30 forks source link

A way to know if an update has been stored (feedback) #28

Open WofWca opened 1 year ago

WofWca commented 1 year ago

Checklist

[x] Are you reporting a bug? Use github issues for bug reports and feature requests. For general questions, please use https://discuss.yjs.dev/ [x] Try to report your issue in the correct repository. Yjs consists of many modules. When in doubt, report it to https://github.com/yjs/yjs/issues/

Is your feature request related to a problem? Please describe. Apparently not all updates are guaranteed to be stored (is it itself a bug? This needs to be documented at least). For example, if you do an update and close/reload the tab immediately, it won't show up on the next load.

There's no conventional way to know in what state the document has been stored in indexedDB. Has the update that I just made been stored? Is it safe to close the tab now?

Describe the solution you'd like Expose some getter, or method, or add an event (or all at the same time), that lets you determine if the document is stored in indexedDB in the same state as it is in JS right now.

Also I guess this should apply to other persistence adapters (leveldb).

Describe alternatives you've considered Perhaps additionally a method that upon calling stores the latest update

Additional context My case: I'm developing an app that builds the state from a list of updates (like this one). The list is an external thing that persists between page reloads. For performance, I want to store the state of the Y.Doc in browser storage in order to not rebuild it from the list of updates each time. For this I need to remember the index of the last update in the list that has been cached in indexedDB. But I don't know the index because it's not guaranteed that every update made on the doc with the y-indexeddb adapter attached will be saved.

dmonad commented 1 year ago

Apparently not all updates are guaranteed to be stored (is it itself a bug? This needs to be documented at least). For example, if you do an update and close/reload the tab immediately, it won't show up on the next load.

This is news to me. How can I reproduce this?

All updates should be stored immediately. A callback should not be necessary.

WofWca commented 1 year ago

This is news to me. How can I reproduce this?

Sorry about that, I guess I misunderstood the source code. Apparently this can happen much rarer than I initially thought, but still does. I think it's when you apply changes to a doc and immediately reload/close the page without waiting for the 'update' event to fire. Might need to double check.

Another thing is to maybe ensure that the changes have been saved to disk.

raineorshine commented 1 year ago

~@WofWca Updates are persisted every 1 second:~

https://github.com/yjs/y-indexeddb/blob/41a5e5964e698f11eb287ea029eb141fe6332039/src/y-indexeddb.js#L95-L98

It would be simple to add an emit('stored') event to the _storeUpdate method.

dmonad commented 1 year ago

All updates are stored immediately. The mentioned timeout is only for trimming the updates.

Persisting can fail if you close the web-app before the last transaction finishes - this should be extremely unlikely. However, I'd be happy to accept a PR that adds an event.

raineorshine commented 1 year ago

Ah, thanks for the correction.

Regardless, IndexedDB can be kind of slow. I find myself closing tabs or switching apps before the data gets persisted pretty frequently. I'm considering a synchronous write to localStorage and then flushing to IndexedDB.