Closed ubruhin closed 11 years ago
Zwei Vorschläge für die Integration in Part-DB: Entweder Scan der Ordnerstruktur und Eintrag in eine Tabelle. Bei Updates der Footprints würde diese Tabelle upgedatet. Den Scan müsste man allerdings immer mal wieder von Hand anstossen, um Fehler zu finden. Allerdings könnte es zu Laufzeit- und Speicherplatzproblemen kommen. Alternativ wäre ein cronjob (oder bei Windows ähnliches), der den Scan und den Abgleich der Tabelle automatisch erledigt, ohne die Probleme von PHP zu bekommen. Ein Perl-Script könnte ich erstellen :-)
Jetzt ist ein neues Problem aufgetaucht: Bei sehr langer Liste fehlerhafter Footprints, kann (je nach PHP Einstellungen) ein Teil der POST-Variablen gelöscht werden. Vor allem die Einstellung "max_input_vars" stellt einen Flaschenhals dar.
Wenn man einfach nur eine gewisse Anzahl Footprints auflisten lässt, wäre dieses Problem auch gleich behoben. Bei der zweiten Variante (zwischenspeichern der Ordnerstruktur) würde dieses Problem nach wie vor bestehen.
Da das Tool zum aktomatischem Korrigieren der Dateinamen grundsätzlich nur in Ausnahmefällen wirklich benötigt wird, denke ich ist es kein Problem wenn wir einfach die einfachere Lösung implementieren, die mit praktisch Null Programmieraufwand alle Probleme beheben sollte.
Wie wehre das vorher die Einstellung auszulesen und dementsprechend die Anzeige zu machen 20 finde ich etwas wenig
z.b. mit ini_get()
Ja, das wäre durchaus auch eine Möglichkeit. Ein Problem an vielen Einträgen ist allerdings ja auch noch, dass die Seite sehr lange zum laden braucht (weil viel im Dateisystem nach Dateien gesucht wird). Bei wirklich vielen Einträgen ist es nicht mehr zumutbar, in der Liste aller Footprints einen Footprint zu selektieren, weil man dann gleich wieder >>10 Sekunden warten muss.
Die beste Lösung wäre wohl, die Ordnerstruktur in ein Array einzulesen und darin nach den gewünschten Dateien zu suchen, damit die Ladezeit stark reduziert wird. Zusätzlich soll auch noch per ini_get() ausgelesen/berechnet werden, wieviele Einträge die Liste maximal haben darf damit alles noch einwandfrei funktioniert. Und dann nur die berechnete Anzahl Einträge in die Liste schreiben (bzw. zur Sicherheit etwas weniger). Wenn es die PHP Konfiguration zulässt, werden alle fehlerhaften Footprints auf Einmal angezeigt, wenn nicht halt nur ein Bruchteil davon.
Also, ich habs jetzt so gemacht dass erstmal mit ini_get() die "max_input_vars" geholt wird (falls vorhanden, diese einstellung gibts anscheinend noch nicht lange). Diese Zahl wird durch 10 dividiert und soviele Footprints werden dann maximal angezeigt (jeder footprint erzeugt 7 POST variablen, die restlichen dienen als "reserve").
Zusätzlich wird jetzt das Dateisystem nur noch einmal nach Dateien gescannt und in ein Array geladen. Die Suche nach ähnlichen Dateinamen erfolgt dann nur noch im Array, was die Geschwindigkeit erhöht.
Und dann habe ich aber auch noch ein Limit von 100 Footprints eingebaut. Allzu viele Footprints machen die HTML Seite sonst nur noch unübersichtlicher und die Tabelle wird immer hässlicher (bei kleiner Bildschirmauflösung und/oder langen Dateinamen sieht die Tabelle sowieso schon sch*\ aus). Ausserdem leidet auch die Ausführungszeit darunter, wenn zu viele Footprints verarbeitet werden müssen... Wo man dieses Limit ansetzt, darüber lässt sich diskutieren. Wenn das Bedürfnis besteht, kann man es auch noch etwas anheben.
Wenn es in der Datenbank sehr viele Footprints mit ungültigen Dateipfaden zu Bildern gibt, braucht die Seite Bearbeiten/Footprints sehr lange zum Laden, was zum Abbruch aufgrund der PHP Einstellung "max_execution_time" führen kann.
Grund:
Mögliche Lösungsansätze:
Bugfix sollte in die Version 0.3.1 aufgenommen werden!