Table of Contents
Attachments and Links
Terminology
- Attachment : Anything that can be attached to a note
- Link : Anything remote linked to in a note
- AttachmentThumbnail : The thumbnail of an attachment
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.
Migrating data from v2
File to Attachment
Direct transformation:
id
=>id
filehash
=>filehash
mimetype
=>mimetype
size
=>size
modified
=>modified
Requires computation:
filename
=> {if file is in storage thenfilename
, else null}width
=> {if file is known by V3, re-compute thenwidth
, else null}height
=> {if file is known by V3, re-compute thenheight
, else null}- Count references and fill
lives
File to Link
Only if url
and urlhash
are not null.
Direct transformation:
id
=>id
url
=>url
urlhash
=>url_hash
File and File_to_post to AttachmentToNote
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_id
post_id
=>note_id
modified
=>modified
Requires computation:
title
??filename
=>title
File_thumbnail to AttachmentThumbnail
For 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.
Embed and StoreRemoteMedia
// TODO