I can get a yText by:
const yText1 = yDoc.getText("some-id1");
const yText2 = yDoc.getText("some-id2");
Can i delete/remove this yText from yDoc?
My use case is, i am currently persistent this yDoc with y-indexeddb.
e.g. it save some text that user input, and user can also delete it, in that case, i would like to delete it from the db as well
Generally Docs preserve their entire change history for conflict resolution purposes. You could set it to an empty string, or have a separate variable that tracks if it has been deleted.
I see, thanks for your response and suggestion!
Could such a Y.Text be added to a Y.Array or Y.Map and properly be deleted later? While this would require an indirection (doc → array|map → text rather than doc → text) the intermediate structure would also help managing the list of Y.Text instances…
That will work, though I don’t think it will permanently deleted it from the database. I think it will just get saved as another update.
The only way I know of to permanently remove updates from the database is to directly modify the updates table/store in the db. Or if you store the text in an entirely separate Doc, then the entire Doc can be deleted from the store (though you lose atomicity with other shared types).
I believe that @dmonad has mentioned that Maps always store their Key history, but not the content history. The content COULD be a y-type that has history, but not always. So you can delete the key “a” from a map, and it would show as “a existed at some point but has been deleted”. I wish I could find that reference…
That’s the “tombstoning” approach which shall avoid that once deleted items suddenly reappear when a partitioned network heals
Well, “deleting” a map entry often means to store a “tombstone” instead, and deleting an array element often just adds the delete operation until the array’s operation log is compacted.
I still do not know how subdocs are handled internally as there seems to be a list of subdocs in the “superdoc”, though
Subdocuments are basically independent Docs, just with some event handling that gets wired up so they get updated and destroyed together. The parent Doc maintains a list of all subdoc guids that can be used to lazy load the subdocs.