Vorteile der datenbankgestützten Dateiverwaltung?

**betatester** · 21.10.2014, 07:23

Ich denke gerade darüber nach, ob die datenbankgestützte Dateiverwaltung wirklich so vorteilhaft ist - oder ob einfach ich diese Vorteile nicht erkenne.

Konkretes Beispiel:
Wir haben bei einem Projekt ein Modul für Produkte. Jedes Produkt hat ein Bild. Es sind bereits mehrere hundert Produkte angelegt. Nun wurden alle Produkte neu fotografiert, dabei wurde darauf geachtet das die Bilddateien die selben Dateinamen haben wir die früheren Bilder. Es würde sich also nun anbieten, einfach alle Bilder zb. per FTP hochzuladen und die alten zu überschreiben. Das geht aber getestetermaßen nicht, weil ja in den Datenbanktabellen der Module überall die UUID der Dateien gespeichert wurde, diese bleibt ja beim Überschreiben nicht gleich. Somit bleibt nur, alle Bilder (wie gesagt, mehrere hundert) in den Module mit dem Dateipicker neu zuzuordnen...

Auch sonst erschließen sich für mich keine Vorteile durch die Referenzierung per UUID. Die einzige Ausnahme dürfte sein, dass die Zuordnung erhalten bleibt, wenn sie in der Dateiverwaltung umbenannt oder verschoben wird. Aber das kommt ja jetzt so häufig auch nicht vor. Da werde ich mit Szenarien ähnlich wie dem oben beschriebenen schon häufiger konfrontiert.

Sehe ich da etwas falsch? Oder erkenne ich irgendwelche Möglichkeiten nicht?

Komischerweise behauptet übrigens ein Kollege, es wäre ihm ab und an durchaus schon gelungen, Dateien per FTP zu ersetzen, ohne das die Zuordnung zu Inhalten verloren ging. Konnte ich jetzt bei diversen Tests nicht nachvollziehen. Selbst wenn ich eine abweichende Datei über die Dateiverwaltung an die selbe Position mit dem selben Namen hochlade, erhält sie (natürlich) eine andere UUID als die überschriebene.

**tab** · 21.10.2014, 08:03

Ich sehe das ähnlich, obwohl ich die Vorteile durchaus nutze und auch schätze. Im alltäglichen Gebrauch während der Entwicklung schätze ich es durchaus, wenn ich ein eigentlich zum Theme gehörendes Bild, das versehentlich bei den Inhalten gelandet ist, mal eben einfach in den passenden Theme-Ordner verschieben kann und alles funktioniert weiterhin. Oder im Betrieb, wenn Bilder von Redakteuren mit unpassenden Dateinnamen ins falsche (oder in ein vorläufiges) Verzeichnis hochgeladen werden. Einfach umbenennen und/oder verschieben und eben nicht lang suchen, wo denn jetzt das Bild verwendet wurde um dort den Pfad anzupassen (und die Hälfte zu vergessen, wenn es mehrfach benutzt wird).

Das sind schon handfeste Vorteile. Die Kehrseite ist das, was du beschrieben hast. Da würde ich mir eine zweite Art von Synchronisation wünschen, die mir auf Knopfdruck überall in der Datenbank die UUIDs anpasst. Und wenn ich sage überall, dann meine ich auch überall. Also in allen Inhaltselementen aber z.B. auch bei verwendeten insert_tags und im internen CSS. Ich muss ein oder mehrere Bilder ohne großen Aufwand direkt in der Dateiverwaltung komplett, an allen Stellen wo sie verwendet werden, ersetzen können, ohne jedes einzelne Inhaltselement anfassen zu müssen. Das ist sonst einfach extrem wartungsunfreundlich.

**Spooky** · 21.10.2014, 08:09

Eigentlich sollte durch einfaches Ersetzen der Dateien per FTP nichts verloren gehen, nach einem Datei-Sync...

Für Dateien, die bereits in der Datenbank existieren, wird nur deren hash aktualisiert in der Datenbank, wenn sich die Datei geändert hat, sonst nichts. Siehe https://github.com/contao/core/blob/...Dbafs.php#L574

**betatester** · 21.10.2014, 08:34

Hmmm... in der Tat. Habe eben auch testweise Dateien über den Upload der Dateiverwaltung aktualisiert, und sie erhielten die selbe UUID, obwohl es völlig andere Dateien sind.

Möglicherweise habe ich dem Konzept unrecht getan. Gleichzeitig frage ich mich jetzt aber, warum ich dann in den letzten Wochen so oft Bilder manuell neu zuordnen musste, nachdem sie ersetzt wurden. Und zwar sowohl wenn sie per FTP ersetzt wurden, als auch über den Filemanager.

**Kahmoon** · 21.10.2014, 08:42

Wenn man eine Datei überschreibt ändert das doch nicht die UUID?? Ich mache das ständig.... allerdings lasse ich meistens danach direkt den Sync laufen. Gab noch nie Probleme.

Das man Dateien übers Backend umbenennen kann oder ganze Ordner verschiebt ohne das die Bilder in sämtlichen News nicht mehr angezeigt werden ist gelinde gesagt ein verdammter Segen

und ein super Feature.

VG

**tab** · 21.10.2014, 08:50

Hmm, kenne ich aber auch anders. Als ich letztens ein paar Bilder optimiert habe und neu hochgeladen, war die Zuordnung weg. Zum Glück war das jeweils immer nur eine Datei und ich wusste auch, wo ich sie neu zuweisen muss. Eine wirklich bildlastige Installation mit Galerien hatte ich bisher mit Contao nicht. Vielleicht habe ich ja irgendwas falsch gemacht dabei, wenn ich mir auch nicht vorstellen kann was das sein sollte. Wenn ich mich recht entsinne war es auch nicht per FTP sondern über die Dateiverwaltung hochgeladen. Muss ich nachher gleich nochmal versuchen nachvollziehen. Bzw war das schon "immer" so? Hmm, muss ich wohl mal mit 3.2.12 vergleichen.

**Spooky** · 21.10.2014, 09:01

Wenn ihr das Reproduzieren könnt, ist das sicher ein Github Ticket Wert. Postet auch die alte und Neue Datei dazu, inkl. Angaben unter welchem OS, PHP Version etc.

**Kahmoon** · 21.10.2014, 09:11

Meine Installation ist sehr sehr bildlastig, da es ein Fotografenportfolio ist. Ich lade Bilder eigentlich zu 80% per FTP hoch. Ab und an auch per Dateiverwaltung. Ich nutze also beides. Bisher alles gut.

Contao 3.3.5 bei All-Inkl

VG

**Spooky** · 21.10.2014, 10:41

Zitat von tab

Wenn ich mich recht entsinne war es auch nicht per FTP sondern über die Dateiverwaltung hochgeladen. Muss ich nachher gleich nochmal versuchen nachvollziehen. Bzw war das schon "immer" so? Hmm, muss ich wohl mal mit 3.2.12 vergleichen.

Vielleicht existiert das Problem ja nur dort. Wie auch immer, wenn es reproduzierbar ist - Anleitung + Dateien gleich auf Github (oder hier) posten.

**betatester** · 21.10.2014, 10:46

Wie gesagt, ich muss manche Aussagen meines Threadstarts revidieren, weil ich sie im konkreten Test auch nicht nachvollziehen konnte.

Ich versuche gerade raus zu finden, warum ich gestern eine Stunde damit zubringen musste haufenweise Bilder per Filepicker neu zuzuordnen, obwohl mein Kollege beschwört, dass er diese alle über die Dateiverwaltung hochgeladen und überschreiben hat...

**tab** · 21.10.2014, 12:24

Ich habs in einer 3.2.14 probiert und konnte es auch nicht mehr reproduzieren

. Werde heute abend mal die konkrete 3.2.12 Installation bei der es passiert ist duplizieren (ist eine produktive Seite) und ein paar Versuche machen.

**betatester** · 21.10.2014, 13:23

Folgendes hab ich jetzt mal probiert.

Wenn ich in der Dateiverwaltung eine Datei ersetze (in dem ich in den selben Ordner einfach eine Datei mit dem selben Namen uploade), bleibt die UUID gleich.

Wenn ich eine Datei in der Dateiverwaltung lösche und anschließend eine Datei mit dem selben Namen in den selben Ordner lande, ändert sich die UUID.

Ersetzen einer Datei per FTP, anschließend synchronisieren: UUID bleibt gleich.

**Kahmoon** · 21.10.2014, 13:27

Zitat von betatester

Wenn ich eine Datei in der Dateiverwaltung lösche und anschließend eine Datei mit dem selben Namen in den selben Ordner lande, ändert sich die UUID.

Das ist aber logisch. Es ist ja auch eine andere Datei mit einem anderen Hashwert.

VG

**Spooky** · 21.10.2014, 13:27

Zitat von betatester

Folgendes hab ich jetzt mal probiert.

Wenn ich in der Dateiverwaltung eine Datei ersetze (in dem ich in den selben Ordner einfach eine Datei mit dem selben Namen uploade), bleibt die UUID gleich.

Wenn ich eine Datei in der Dateiverwaltung lösche und anschließend eine Datei mit dem selben Namen in den selben Ordner lande, ändert sich die UUID.

Ersetzen einer Datei per FTP, anschließend synchronisieren: UUID bleibt gleich.

Also funktioniert alles

Dass sich die UUID ändert wenn du eine Datei vorher löschst und dann neu hinauf lädst ist klar.

**Spooky** · 21.10.2014, 13:30

Zitat von Kahmoon

Das ist aber logisch. Es ist ja auch eine andere Datei mit einem anderen Hashwert.

VG

Mit dem Hash hat das nichts zu tun, die UUID ist eine zufällig erzeugte ID, die in keiner Weise etwas mit der Datei selbst zu tun hat. Die Erzeugung der UUID findest du hier: https://github.com/contao/core/blob/...ysqli.php#L313

Selbst wenn du die selbe Datei nochmal hinauflädst, nachdem du sie aus der Datenbank gelöscht hast, wird sie eine neue, andere UUID bekommen.

**betatester** · 21.10.2014, 13:30

Stimme ich zu. Werde weiter prüfen ob mein bisheriger Eindruck auf Anwenderfehler zurück zu führen ist. Weil ganz kapieren tu ich es noch nicht wie es zu dem anfangs von mir beschriebenen Verhalten kam, alle Beteiligten schwören, nichts gelöscht - sondern lediglich ersetzt zu haben.

Danke auf jeden Fall für die Diskussion und die Klärung.

**betatester** · 21.10.2014, 13:33

Zitat von Kahmoon

Das ist aber logisch. Es ist ja auch eine andere Datei mit einem anderen Hashwert.

VG

Das würde auch beim überschreiben ohne vorigem Löschen zutreffen.

**Kahmoon** · 21.10.2014, 13:39

Hmm ich weiss nicht genau wovon dieser Hash abhängt und ob dieser eine Tolleranz hat.

**Spooky** · 21.10.2014, 13:54

Der hash hat mit der UUID nichts zu tun.

**Kahmoon** · 21.10.2014, 13:59

OK

**betatester** · 21.10.2014, 14:00

Eventuell Offtopic:
Ich bin noch nicht lang genug mit von der Partie hier um ausreichend mitbekommen zu haben warum damals die Referenzierung von IDs auf die UUIDs umgestellt wurde. Was genau ist hier der Vorteil?

**Kahmoon** · 21.10.2014, 14:16

Referenzierung war nie auf IDs wenn ich richtig liege, sondern auf Dateinamen. Zumindest bei Inserttags. Genau deshalb sind die IDs ja der Vorteil.

**Spooky** · 21.10.2014, 14:19

Zitat von betatester

Eventuell Offtopic:
Ich bin noch nicht lang genug mit von der Partie hier um ausreichend mitbekommen zu haben warum damals die Referenzierung von IDs auf die UUIDs umgestellt wurde. Was genau ist hier der Vorteil?

Die ID ist nur eine fortlaufende Zahl und identifiziert einen Datenbank-Eintrag nicht eindeutig über mehrere Installationen hinweg. Die UUID dagegen identifiziert einen einzelnen Datenbank-Eintrag eindeutig.

Wichtig war das bspw. auch für die Synchronisation des Datenbankgestützten Dateisystems via syncCto.