[UI] Support repo snapshots

[senwang86]

Summary

• Creating a new database table called YDocSnapshot that stores repo snapshots at the request of users.
• The implement features a strict database consistency, once receiving a request, it reads the yDocBlob in the Repo table and inserts it into YDocSnapshot. It avoids conflicts between Repo.yDocBlob in the event of network interruption.
• "Rename/restore/delete" operations will be added after discussion.

Test

• Attach the shell of the api docker container
• Run npx prisma migrate dev
• Restart api container

[lihebi]

One last comment: merge the two migrations into one? I.e. remove the migrations and re-generate one.

[senwang86]

One last comment: merge the two migrations into one? I.e. remove the migrations and re-generate one.

d291948 address this.

[lihebi]

Awesome, thanks!

[lihebi]

Since this PR involves DB schema change, I'd like to ensure that the restoring would work under this design before merging.

I was thinking about how to restore a snapshot. Two methods:

• Option 1 (not ideal): Directly replacing the ydoc to a previous state. This isn't ideal, as the peers see a different yDoc with different history, impossible to sync.
• Option 2 (ideal): Add a new "restoring" changeset on top of the latest ydoc. This should be the ideal way.

In terms of implementation, I found that Yjs has a "Y.Snapshot". So instead of storing a whole YDocBlob into snapshots, we could store a Y.Snapshot binary and use Y.snapshot APIs for restoring. But this snapshot seems to only support method 1, which is not ideal.

To support method 2, we might need to implement a "restoring" changeset, like mentioned here.

I'll need some time to think about it before we merge this PR and work on restoring.

[senwang86]

Realized that the YDocSnapshot needs a field of userId to separate the snapshots among various collaborators. WDYT, @lihebi ?

[lihebi]

I don't think so. The snapshot is associated with the repo. Each repo has only one line of snapshots, regardless of which user triggered it.

[senwang86]

I don't think so. The snapshot is associated with the repo. Each repo has only one line of snapshots, regardless of which user triggered it.

Will the snapshot list show snapshots from all other collaborators?

[lihebi]

Yes. There's only one snapshot line for the repo; everyone sees and operates on it. Keep it simple.

[lihebi]

There are more things to consider.

I've been thinking about how to make the revision system to:

1. play well with the Git system and
2. to be able to function on scopes

Also, the revision system code wouldn't need to be included in the public-facing desktop app. It would be exclusive to SaaS app, meaning the code would be in another repo.