C’est super ! Très bonne solution. 
Je me demande si l’utilisation de la même stratégie de suppression des références de téléchargement de markdown dans les publications pourrait être judicieuse pour le scénario inverse, lorsqu’un téléchargement est détruit mais que les publications qui y font référence restent actives.
Si je détruis un téléchargement comme :
Upload.find(123).destroy
Si le téléchargement 123 était utilisé par des utilisateurs pour :
- l’avatar personnalisé du profil
- l’arrière-plan du profil
- l’arrière-plan de la carte
Toutes les références sont supprimées, apparemment de :
before_destroy (efface les références de téléchargement d’arrière-plan/bannière de carte)
after_destroy (efface les références de téléchargement d’avatar)
Si les identifiants de publication associés à un identifiant de téléchargement pouvaient être utilisés pour mettre en file d’attente la suppression du markdown de téléchargement lors de sa destruction, je pense que cela pourrait potentiellement empêcher les références de téléchargement mortes dans les publications non supprimées lorsqu’un téléchargement est détruit manuellement.
Idéalement, conserver le markdown de téléchargement pour tous les identifiants de téléchargement qui n’ont pas été détruits, si, par exemple, une publication contient deux téléchargements mais que seul l’un d’eux a été détruit.
Par exemple, si la suppression d’un téléchargement référencé dans plusieurs publications (telles que les publications de citation) via https://meta.discourse.org/t/legal-compliance-plugin/356331 ou la console Rails.