Not every Link has an attachment. An attachment is created for a link when it becomes something attachable. So happens when additional information on a link's URL becomes available.
Following how it is done with Links, anything with a thumbnail in GNU social must have an attachment as only attachments can have a thumbnail.
This design prevents file and thumbnail duplication, thus saving storage.
An example of a module making use of this system is the Avatar component. It creates an attachment and uses the thumbnail route to access different avatar sizes via the AttachmentThumbnail controller.
Direct transformation:
id => idfilehash => filehashmimetype => mimetypesize => sizemodified => modifiedRequires computation:
filename => {if file is in storage then filename, else null}width => {if file is known by V3, re-compute then width, else null}height => {if file is known by V3, re-compute then height, else null}lives
Only if url and urlhash are not null.
Direct transformation:
id => idurl => urlurlhash => url_hash
Direct transformation by joining File f and File_to_post fp on id = file_id with fp.file_id, fp.post_id, f.title, f.filename, fp.modified:
file_id => attachment_idpost_id => note_idmodified => modifiedRequires computation:
title ?? filename => titleFor every attachment where we have the original (filename not null), just let them be regenerated on request. For all the others, compute the mime-type and rescale to the new default sizes.
The field url from File_thumbnail has duplicated information that was already migrated in the tables above and can, therefore, be safely ignored now.
// TODO