[UI] Support repo snapshots

codepod-io / codepod

Codepod IDE: Scalable Interactive Coding

https://codepod.io

MIT License

74 stars 15 forks source link

[UI] Support repo snapshots #462

Open senwang86 opened 1 year ago

senwang86 commented 1 year ago

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

add_snapshots

lihebi commented 1 year ago

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

senwang86 commented 1 year ago

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

d291948 address this.

lihebi commented 1 year ago

Awesome, thanks!

lihebi commented 1 year ago

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 commented 1 year ago

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

lihebi commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

lihebi commented 1 year ago

There are more things to consider.

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

play well with the Git system and
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.