The goal of this PR is to make a decision on how to store file and folder metadata in the database. I'm specifically avoiding anything to do with the REST API, and even validation & data constraints at this time.
The approach I've written here is to store a user-defined metadata field on each file and folder as a JSONB column. However, realizing that the use of metadata on these objects is likely to be very sparse, another reasonable approach would be to add the metadata in a separate relation e.g. (file_id: FK, metadata: JSONB) and only store a row if the metadata object is non-empty. I chose the former approach because disk is cheap and I assume we'll almost always want to return this value, but I could be persuaded either way. I'm also open to completely different approaches for storing metadata if people have other ideas.
The goal of this PR is to make a decision on how to store file and folder metadata in the database. I'm specifically avoiding anything to do with the REST API, and even validation & data constraints at this time.
The approach I've written here is to store a user-defined metadata field on each file and folder as a JSONB column. However, realizing that the use of metadata on these objects is likely to be very sparse, another reasonable approach would be to add the metadata in a separate relation e.g.
(file_id: FK, metadata: JSONB)
and only store a row if the metadata object is non-empty. I chose the former approach because disk is cheap and I assume we'll almost always want to return this value, but I could be persuaded either way. I'm also open to completely different approaches for storing metadata if people have other ideas.