You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The model is just posited as self-obvious, but it's very much not. The idea of "file on disk, metadata in database" is fairly easy to grasp, but "file on disk, metadata in database, meta-metadata also in database" is not.
It doesn't help that the virtual file has essentially an identical model to the physical file. The dual layer makes the model unwieldy in development, so it would be nice to know the reason why.
The text was updated successfully, but these errors were encountered:
For me one of the main values of this split is that you can safe both the filename a user expects to see (my-file-1.pdf) vs how it's stored xyz.pdf. It also allows you to store the file in multiple locations. This is a very common pattern in describing assets (an abstract form and then an "item" form which describes how 1 instance of the asset is stored) and as such was not deemed necessary to explain.
The model is just posited as self-obvious, but it's very much not. The idea of "file on disk, metadata in database" is fairly easy to grasp, but "file on disk, metadata in database, meta-metadata also in database" is not.
It doesn't help that the virtual file has essentially an identical model to the physical file. The dual layer makes the model unwieldy in development, so it would be nice to know the reason why.
The text was updated successfully, but these errors were encountered: