In D3463#41959, @machniak wrote:

In D3463#41947, @vanmeeuwen wrote:

In D3463#41941, @machniak wrote:

• If we move file name, size, mimetype to a separate table whenever we want to list/sort/search we have to make join(s) which will make it slow, and I'd say listing/searching by these three attributes is essential. A simplest listing needs to return at least the file size, name and mimetype, this makes this basic query much complicated/slower.

The assumption is that most if not all "lists" of "files" do not contain a column for the attributes such as size, mtime nor mimetype, let alone allow for "sorting by".

Most? All file managers/pickers I know display file name, size and mtime (mimetype is often used to display a different icon).

Furthermore, a "list of files" even with metadata does not require us to use a single roundtrip -- it can be a) a list of files and b) get some metadata -- avoiding joins.

Not if you sort by or search by these fields. And sorting by size/name/mtime is essential.

In D3463#41941, @machniak wrote:

• If we move file name, size, mimetype to a separate table whenever we want to list/sort/search we have to make join(s) which will make it slow, and I'd say listing/searching by these three attributes is essential. A simplest listing needs to return at least the file size, name and mimetype, this makes this basic query much complicated/slower.

Some high-level observations from a first glance:

• The permission->id is used as the unique identifier for a share-link, which means the same user will always get the same link, but each user will receive a different link.
• Instead of reassembling files individual chunks are now stored, which means we can save ourselves the hassle of reassembling the files and just serve the same chunks for download (I suppose? Haven't checked)