Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Versions 2.0 #9445

Open
rullzer opened this issue May 10, 2018 · 2 comments
Open

Versions 2.0 #9445

rullzer opened this issue May 10, 2018 · 2 comments
Labels

Comments

@rullzer
Copy link
Member

rullzer commented May 10, 2018

@icewind1991 as discussed

Right now versions are handled suboptimal.

  • When a file is moved to the trash all the versions are moved as well
  • When a file is moved back all the versions are moved again

This basically puts a huge load on the server. Because it has to move data around. Better would be to just store the versions on a logical place (by default appdata as versions don't count towards quota anyway). That way the files can just stay where they are and we only start deleting them when they are all removed from the system.

Removal could be done similar to #9420 so in a backgroundjob.

  • Shared files don't mean shared versions

Right now versions are bound to a user not to a file. Being bound to a file makes more sense as it will allow shared versions.

We would need to filter out versions from before the share time. So that other usres can't see my pre-cleanup versions.

  • No storage versioning support

S3 for example has native versioning. It would be awesome to use that to save a lot of transfers back and forth.

Idea:

Storages can declar a versionhandler (or whatever you call it). By default this is our base handler that will store versions in appdata. But S3 home storage could do other things.

The current files_versions app would contain basically 2 small apps:

  1. The default version handler. To implement the default versioning.
  2. The DAV API to list/see/delete/restore versions
  • This interfaces with the storage versionhandler

Of course it will also need to handle the current versions in a hybrid way. As migrating this all over will have to happen live to avoid significant downtime.

Limitations:

I would propose to have the version handling for now bound to the main storage. So if you have S3 you can eventually move to S3 versions if you have 'normal' storage you can have that.

Else we'll have to start moving versions around cross storage. Which I want to avoid.

Open questions:

What to do if a recipient moves a file out of a shared folder?

@rullzer rullzer added enhancement 1. to develop Accepted and waiting to be taken care of feature: versions labels May 10, 2018
@rullzer rullzer changed the title Version 2.0 Versions 2.0 May 10, 2018
@icewind1991
Copy link
Member

I would suggest to start with just changing how we store versions to be based on fileid and leave the per-storage bit for now. That gives us most of the advantages and we wont have to worry about the whole cross storage moving part yet.

@nextcloud-bot nextcloud-bot added the stale Ticket or PR with no recent activity label Jun 20, 2018
@skjnldsv skjnldsv removed stale Ticket or PR with no recent activity labels Jun 12, 2019
@szaimen
Copy link
Contributor

szaimen commented May 21, 2021

I suppose this issue is still valid? If not, please close this issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants