I’m implementing schema versioning on top of YJS by adding an ‘App Version’ and a ‘Doc Version’.
If (App Version < Doc Version) abort and inform the user they need to update the app.
If (Doc Version < App Version) pause all observers on Y.Doc and run migrations to bring the Doc Version up to date.
The Doc Version is stored in the update format we’ve created ex: { update: …, version: 2 }. And the App Version is a constant that’s updated when we deploy a new version of the app.
The problem is in order to run the migrations, we need to apply the (older) update, which will trigger any existing observers for data on that Y.Doc (and in the case of a prosemirror schema change, result in data loss). Ideally there would be a way to pause observer calls, run the migrations and then resume them.
I think the second case If (Doc Version < App Version) does not work in collaborative systems.
You can only have one instance running the migration at the same time. It is likely that two concurrent migrations would result in weird behavior.
What exactly do you mean by “migration”? Is this some kind of schema change on the prosemirror document?
I would expect that when Doc Version < App Version we need to wait for the server to perform the migration. Once we observe Doc Version === App Version) we can continue binding the editor to the editor. In the meantime, you probably want to show some kind of loading icon because you can’t do anything useful with the unmigrated data that you still might have from previous sessions.
Right, that makes sense. It wouldn’t work in a collaborative system. We’ll switch to running this on the server.
Migration = either a Prosemirror Schema change with a corresponding script to transform any Y.XmlFragments or a change to a Y.Map’s shape. e.g. we add a new Node to the Prosemirror schema or change an existing one, we’d need to transform the data accordingly.