Versions 2.0 #9445
Labels
1. to develop
Accepted and waiting to be taken care of
enhancement
feature: versions
needs review
Needs review to determine if still applicable
performance 🚀
@icewind1991 as discussed
Right now versions are handled suboptimal.
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.
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.
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:
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?
The text was updated successfully, but these errors were encountered: