deleted_files

Note currently we do not use a table to store deleted pages. One of solutions in T20493: RFC: Unify the various deletion systems represents deleted pages using one bit field, so there are no need for a deleted pages (or archive/deleted revisions) table. Similarly we can use a bit field to indicate whether a file is deleted. This will also have the benefit of keeping the (upcoming) file ID upon deletion and undeletion.

Per T28741#9912401, we may want a new table to stored normalized img_media_type, img_major_mime and img_minor_mime.

Per parent task needed columns are:
file table:

• file_id
• file_latest
• file_name
• file_type (normalized type)
• file_delete

filerevision:

• fr_id
• fr_file
• fr_archive_name (if can not be generated automatically)
• fr_size
• fr_width
• fr_height
• fr_bits
• fr_description_id
• fr_actor
• fr_timestamp
• fr_metadata
• fr_type (normalized type)
• fr_deleted (for revdel)
• fr_sha1 (if we need to keep backwards compatibility)
• fr_delete (for normal deletion, unless unified with revdel - see T20493)
• fr_sha256
• fr_perceptual_hash

CC @Ottomata @Milimetric @Ahoelzl @lbowmaker @WDoranWMF

This might affect some data we sqoop into HDFS and some of how we compute commons impact metrics or similar future metrics. We have to wait until a schema change is proposed to know for sure.