oc_filecache brainstorming

[MorrisJobke]

7 minutes:

Queries:

SELECT              2.475.603
oc_appconfig          739.828
oc_share_external     323.974
oc_filecache          239.205
oc_storages           156.746
oc_share              146.976
oc_group_user         144.276
oc_preferences         89.914
oc_users               80.953
oc_properties          69.598
oc_mimetypes           51.215
oc_share_external           0
oc_ldap_user_mapping        0
UPDATE                 30.847
DELETE                  2.088
INSERT                  1.084
Connect                52.458

Full log see s3/engineering/DB-queries

[PVince81]

@cmonteroluque @icewind1991 @Xenopathic @blizzz @nickvergessen @schiesbn

[PVince81]

and @DeepDiver1975

[karlitschek]

Let me summarize what we want to do here from my point of view.

• Remove the joins between sharing and file cache tables.
• Improve the storage API so that a storage plugin can provide all data and metadata like etags, fileids and more.
• Transform our current file_cache implementation into a storage plugin. Other storage plugins can then be implemented by us or others.
• Implement a plugin API for different backends for versioning
• Implement a plugin API for different backends for trashbin
• Implement a plugin API for different backends for sharing
• Use flysystem for some external storages as 'connector/driver'

[PVince81]

Mount points table will be required soon to be able to properly resolve fileid to owner from a cron job.
Ticket here #15166

[PVince81]

I suppose we'll want to continue this for 9.1.
We already have abstraction for sharing, comments, system tags.

We could continue by abstracting versions and trashbin.

[PVince81]

Do we have time to continue this in 10.0 ? Else move to backlog.
The discussion can continue nevertheless.

The ticket itself is unclear as it contains too many suggestions, we need a focus. AFAIK there are already other tickets for individual items

@butonic @DeepDiver1975 @mrow4a

[PVince81]

ongoing discussion, backlog