We know that Y.logUpdate() is experimental. However, we like that it gives us a simple list of changes much like how the observers work on the Shared Types. We are using Yjs for it’s realtime collaboration and we want to persist our data in a format that can work for other apps using the same database data (i.e agents and devices, basically non-humans). When a client connects for the first time we create a ydoc for that customer then every subsequent client in the same customer room gets the same ydoc. We’d love to diff what we initially created with current client changes in order to persist to our database’s rigid data format using something like Y.logUpdate() before we destroy the ydoc after all clients have disconnected instead of storing a state vector as our persistence.
Welcome @john_champds to the discussion board,
Y.logUpdate does not allow you to persist any data. I also don’t recommend to store the information that it prints. Instead, you should persist the normal document updates. You also don’t need to store state vectors as they are only needed to compute the differences. There are some examples on how to interact with Yjs updates on the documentation website: Document Updates - Yjs Docs
Hi @dmonad! Thank you! And thank you for your quick response! And also thank you for your work on this project.
I’m sorry, I wasn’t really clear what our goal is, in a nut shell, we want to know which top-level types have changes by key (we are using ymaps) so we can persist those to the database.
We have a legacy data structure that is stored in a mysql database. We would like to release the next version of our platform with real-time collaboration as a feature. So we take the data we have in the database and use that to populate a ydoc. We would like to persist the data in the same format we got it in. We were thinking that we could use some form of either Y.mergeUpdates() or Y.diffUpdate() to diff the original yDoc we created with the one that has been updated by the customers. Though, we couldn’t get a clean picture of the changes from either.
Then we found what Y.logUpdate() prints, which is essentially a change log much like what we are using in our client when we observe our yMaps.
We really want something like the observer format, but for the whole YDoc. So we can say, oh since we’ve created this ydoc this piece has been updated, added, or deleted lets persist those changes to the database as such.
Is that something that’s possible? Or are we just trying to force Yjs into doing something it’s not really designed to do?
Why don’t you simply observe the Yjs document for changes using the .observe(..) API?
That is exactly what we ended up doing yesterday. We attached event emitters in node to the observe API to create a list of changes that our persistence agent can crawl periodically and make appropriate changes to the database.
This way is waaay simpler than what we were trying before! Thanks for the help!