Es gibt einige Situationen, in denen Benutzer möchten, dass Uploads in Discourse behalten werden, die nicht streng mit bestehenden Discourse-Modellen und Eigenschaften verknüpft sind, die Uploads unterstützen – also „freigegebene“ oder „whitelisted“ verwaiste Uploads.
Beispielsweise möchten einige Personen das Custom Wizard-Plugin verwenden, um Inhalte hochzuladen, die einem Thema zugeordnet sind (nicht unbedingt einem einzelnen Beitrag).
Das Problem besteht darin, dass der clean_up_uploads-Job alle verwaisten Uploads entfernt. Die Ausnahmen beschränken sich auf URLs in bestimmten Site-Einstellungen.
Sie könnten den clean_up_uploads-Job当然 deaktivieren oder die clean_orphan_uploads_grace_period_hours-Einstellung erhöhen, was ich manchmal tun muss. Dies ist jedoch nicht ideal.
Vielleicht gibt es eine andere Möglichkeit, verwaiste Uploads über ein Plugin zu „whitelisten“, die mir entgangen ist. Falls nicht, wäre es großartig, einen Mechanismus dafür in den Upload-Bereinigungsprozess aufzunehmen.
Ich würde gerne eine PR in diese Richtung vorbereiten, frage mich jedoch, ob andere dies ebenfalls als Problem betrachten.
Für Reviewables hat @eviltrout einen allgemeinen Mechanismus eingeführt, über den beliebige Objekte mit einem Reviewable verknüpft werden können.
Auf ein ähnliches System für Uploads umzusteigen, wäre wie der Umzug mehrerer Berge. Es wäre zwar ein schöner Berg, den man versetzen könnte, denn das aktuelle System ist ziemlich anfällig.
Der einfachste Workaround, den du vorerst hast, ist die Erstellung einer versteckten Site-Einstellung mit einem data_type für :upload. Lege sie dann in der Tabelle der Site-Einstellungen ab.
Ja, das habe ich auch in Betracht gezogen. Als Lösung gefällt mir das nicht so gut, da ich für jeden Upload eine eigene Einstellung erstellen müsste, was sich wie ein Missbrauch der site_settings-Tabelle anfühlt.
Als Übergangslösung, bevor der Berg versetzt wird, hätte ich etwas dagegen, wenn ich einen PR einreiche, um eine weitere Ausnahme für die große Abfrage „exceptions
Diese Abfrage ist bereits SOOOO langsam, ich befürchte, dass ein weiterer Join hier alles sehr schmerzhaft machen wird.
Ich bin mir nicht sicher, aber vielleicht fangen wir damit an, die neue Tabelle in Core für UploadRefrence(object_id, object_type, upload_id) vorzubereiten und dort hineinzujoinen. Zumindest ist das kostengünstig, und dann können wir Dinge dorthin verschieben. Es gibt einige einfache Verschiebungen, nur Uploads von Posts wären kniffliger.
Ich denke, das ist Arbeit, die ich lieber dem Team hier überlassen würde, es ist sehr fummelig.
Meinst du damit die Single Table Inheritance von Rails? Das passt sehr gut zu Reviewables, da es eine Kernlogik gibt, die alle teilen, aber zusätzliche Felder haben.
In diesem Fall scheint das Problem jedoch darin zu bestehen, dass wir Upload-IDs überall verteilen und die Uploads nicht löschen, wenn sie entfernt werden?
Ist es unsicher, einen Upload zu löschen, wenn ein Benutzer ihn aus seinem Profil entfernt, weil dieselbe Upload-SHA1 an anderer Stelle in der App verwendet werden könnte? Wenn das der Fall ist, halte ich @sams Vorschlag einer UploadReference-Tabelle für eine gute Lösung.
Wenn Uploads auf diese Weise nie geteilt werden, wäre meiner Meinung nach eine bessere Lösung, sie zu löschen, wenn diese Felder auf NULL gesetzt werden.
Genau aus diesem Grund benötigen wir die UploadReference-Tabelle
Ich persönlich halte das für eine sehr gute Aufgabe, um mehr über die Discourse-Interna zu lernen. Das könnte eine gute Aufgabe für @cvx sein, beginnend Anfang Oktober. Wir werden ein paar Pair-Programming-Sessions machen, um den Einstieg zu erleichtern und die Arbeit ordentlich in mehrere „kleine
Ich habe großes Interesse an einer UploadReference-Tabelle. Wir befinden uns in einer Situation, in der es in Plugins viele hochgeladene Dateien gibt, die als verwaiste Uploads gelten würden. Unsere Lösung besteht einfach darin, clean_up_uploads zu deaktivieren. Ich habe neulich nachgesehen, und wir haben jetzt 10 GB an verwaisten Uploads, die manuell mit einem Skript entfernt werden müssten, das auch prüft, ob wir einige davon in unseren Plugins referenzieren. Eine Lösung wie die, die hier diskutiert wurde, würde uns sehr helfen.
Außerdem, zum Thema: In einigen Fällen verweisen wir auf Uploads ausschließlich mit HTML--Tags. Dies scheint den „Bake“-Prozess dieser Beiträge zu unterbrechen, und andere Dinge wie Hyperlinks werden nicht „gebacken“. Ich sehe, dass Uploads allgemein in der Form upload://.png referenziert werden. Meine Frage ist: Wo kann diese -Zeichenkette gefunden werden? Soweit ich sehen kann, wird sie nicht im Upload gespeichert.
