feat: Fully support storing content-type in file extensions #268
Conversation
| const link = await this.resourceMapper.mapUrlToFilePath(identifier, metadata.contentType); | ||
|
|
||
| // Check if we already have a corresponding file with a different extension | ||
| await this.verifyExistingExtension(link); |
There was a problem hiding this comment.
Just wondering if there are cases where something could go wrong inbetween this and the writing of the file.
The chance this could happen is probably very small, but in case it could, should we somehow move this verification (and removal) to after the writing of the file?
It's better to have two files after a crash than none at all.
There was a problem hiding this comment.
True, there's something to be said for that. The mapper is going to start crashing (or behaving weirdly, no idea) once there are two such files though but at least you still have your data I guess?
There was a problem hiding this comment.
On second thought going to leave it as is since this would require more rewriting than I first thought. Can always be changed later if really required.
Resolves #146 .
Makes sure to update the file path if the content-type gets updated and makes the metadata paths be independent of the content-type.
Also renamed all references from "data resource" to "document" for consistency.