Conversation
api/src/typedefs.ts
Outdated
| repoId: String | ||
| createdAt: String | ||
| message: String | ||
| yDocBlob: String |
There was a problem hiding this comment.
This blob doesn’t need to be sent to the front end.
There was a problem hiding this comment.
This blob doesn’t need to be sent to the front end.
SG, I was thinking about the "restore" operation, I am not exactly sure if it's better to pass the yDocBlob in a single query.
There was a problem hiding this comment.
Restore should probably happen in the backend yjs server, and front end will retrieve from yjs. I’ll think about this.
api/src/resolver_repo.ts
Outdated
| id: await nanoid(), | ||
| yDocBlob: repo.yDocBlob, | ||
| message: message, | ||
| repoId: repoId, |
There was a problem hiding this comment.
Use the connect clause to connect the two tables.
api/src/resolver_repo.ts
Outdated
| */ | ||
| async function getRepoSnapshots(_, { repoId }) { | ||
| const snapshots = await prisma.yDocSnapshot.findMany({ | ||
| where: { repoId: repoId }, |
api/prisma/schema.prisma
Outdated
| createdAt DateTime @default(now()) | ||
| message String? | ||
| yDocBlob Bytes? | ||
| Repo Repo? @relation(fields: [repoId], references: [id]) |
There was a problem hiding this comment.
Lower case “repo” field name.
api/prisma/schema.prisma
Outdated
| createdAt DateTime @default(now()) | ||
| message String? | ||
| yDocBlob Bytes? | ||
| deleted Boolean @default(false) |
There was a problem hiding this comment.
I don't want to add deleted here since it adds complexity. We could reply on DB backup if we really want to ensure data safety.
There was a problem hiding this comment.
I am not so familiar with DB backup, any reference for its pros and cons? I am considering a scenario where users might decide to delete a snapshot, but then want to undo the deletion later. Furthermore, if there are 1,000 users performing these operations at different times, can DB backups gracefully address this scenario?
There was a problem hiding this comment.
I'd skip this scenario for now. If the user deletes it, it is deleted.
There was a problem hiding this comment.
I'd skip this scenario for now. If the user deletes it, it is deleted.
OK, let me revert the change.
api/prisma/schema.prisma
Outdated
| message String? | ||
| yDocBlob Bytes? | ||
| deleted Boolean @default(false) | ||
| repo Repo? @relation(fields: [repoId], references: [id]) |
There was a problem hiding this comment.
yDocBlob and repo/repoId sound to be required, not optional. I.e.,
yDocBlob Bytes
repo: Repo
repoId: String
This reverts commit 880c04c.
| message String? | ||
| yDocBlob Bytes? | ||
| repo Repo? @relation(fields: [repoId], references: [id]) | ||
| repoId String? | ||
| yDocBlob Bytes | ||
| repo Repo @relation(fields: [repoId], references: [id]) | ||
| repoId String | ||
| } |
There was a problem hiding this comment.
You need to generate a new DB migration to reflect this change.
|
One last comment: merge the two migrations into one? I.e. remove the migrations and re-generate one. |
d291948 address this. |
|
Awesome, thanks! |
|
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:
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. |
|
Realized that the |
|
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? |
|
Yes. There's only one snapshot line for the repo; everyone sees and operates on it. Keep it simple. |
|
There are more things to consider. I've been thinking about how to make the revision system to:
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. |
Summary
YDocSnapshotthat stores repo snapshots at the request of users.yDocBlobin theRepotable and inserts it intoYDocSnapshot. It avoids conflicts betweenRepo.yDocBlobin the event of network interruption.Test
apidocker containernpx prisma migrate devapicontainer