Bauteile-Import: PHP Limit "max_input_vars" wird überschritten

[ubruhin]

Beim Bauteile-Import wird ziemlich schnell das PHP Limit "max_input_vars" (Standardmässig auf 1'000 eingestellt) überschritten. Der Import funktioniert dann einfach nicht, und es wird keine Fehlermeldung angezeigt.

Da pro Bauteil aktuell 13 Variablen per POST übermittelt werden, funktioniert der Import (bei max_input_vars=1000) nur bis ca. 75 Bauteile. CSV-Dateien mit mehr als ca. 75 Zeilen gehen also nicht mehr.

Fragt sich jetzt, ob man die Ursache des Problems (die vielen übermittelten Variablen) gescheit beheben kann, oder ob man einfach die Anpassung von "max_input_vars" in die .htacces und in die Doku aufnehmen und ggf. im Importer den Fehler noch mit einer Fehlermeldung abfangen soll...

[ajfre]

Immerhin gibt es ja einen Workaround um trotzdem grössere Dateien importieren zu können.

Das ist halt eine ewige Fehlerquelle, zumal man überhaupt keine Hinweise auf die Ursache bekommt.

Woher kommen denn diese xml-Dateien?

[ajfre]

Die Änderung in /etc/php5/apache2/php.ini bewirkt bei mir überhaupt nichts: die Anzeige bricht nach der 194. Zeile ab, ein Übernahme-Button wird nicht nicht angeboten. Das Zufügen der Zeile 'php_value max_input_vars 10000' zu /var/www/part-db/.htaccess ebensowenig.

(Ich habe die VM, in der der Server läuft, schon mehrfach neu gestartet.)

[ubruhin]

Woher kommen denn diese xml-Dateien?

Das weiss ich leider auch nicht, ich glaube das war schon drin als ich mit der Weiterentwicklung von Part-DB begonnen habe... Ich gehe mal davon aus, dass es schon einen Grund gab das einzubauen, daher würde ich es nur ungerne wieder rauswerfen.

Die Änderung in /etc/php5/apache2/php.ini bewirkt bei mir überhaupt nichts: die Anzeige bricht nach der 194. Zeile ab

Sicher, dass die Datei mehr als 194 Zeilen hat? :) Die Datei, die du mir geschickt hast hat nämlich genau 194 Zeilen (ohne Header). Wenn das hochsetzen von max_input_vars nicht geklappt hätte, würde der Import schon nach ca. 75 Zeilen abbrechen.

[ajfre]

Sicher, dass die Datei mehr als 194 Zeilen hat? :) Sie hat 194 - Du hast recht. Ich hatte den zweiten Button vermisst, aber der erscheint erst nach der Überprüfung der Daten... Intuitive Bedienbarkeit ist das nicht...

On 02.01.2016 22:03, U. Bruhin wrote:

Woher kommen denn diese xml-Dateien?

Das weiss ich leider auch nicht, ich glaube das war schon drin als ich mit der Weiterentwicklung von Part-DB begonnen habe... Ich gehe mal davon aus, dass es schon einen Grund gab das einzubauen, daher würde ich es nur ungerne wieder rauswerfen.

Die Änderung in /etc/php5/apache2/php.ini bewirkt bei mir
überhaupt nichts: die Anzeige bricht nach der 194. Zeile ab

Sicher, dass die Datei mehr als 194 Zeilen hat? :) Die Datei, die du mir geschickt hast hat nämlich genau 194 Zeilen (ohne Header). Wenn das hochsetzen von max_input_vars nicht geklappt hätte, würde der Import schon nahc ca. 75 Zeilen abbrechen.

— Reply to this email directly or view it on GitHub https://github.com/sandboxgangster/Part-DB/issues/47#issuecomment-168428048.

[ubruhin]

Why not using English globally in the project? It would gain more user base.

Yes, I agree with you. Until now, Part-DB does not have a multilingual web-interface and it would require some work to add multilingual support. But as there are no active developers at the moment, nobody can implement this new feature.

Feel free to fork Part-DB and make a pull-request for adding multilingual support :smile:

[sandboxgangster]

ajfre Da kann es noch andere Sachen geben erhöhe mal den Speicher für die maximalen String Größen der ist standardmäßig auf "8M" 16M sollten besser gehen, wir hatten das Thema auch schon in dem PartDB Tehma (ka ob im ersten oder zweiten)im µC.net, die maximale Ausführungszeit kann noch ein Problem sein und bei PHP_Patches muss man es auch zusätzlich noch einstellen.

Mit PHP_info () solltest mal überprüfen ob die Änderungen übernommen wurden.

[ajfre]

Offenbar weiß keiner, was es mit dem xml-Eingabeformat auf sich hat. Deswegen mein Vorschlag: raus damit.

Wenn jemand xml-Daten importieren will, dann soll er sich ein xslt-Skript bauen, das aus der xml-Datei (mittels xsltproc) eine csv-Datei baut. (Z.B. erzeugt kicad 4 durch einen xsltproc-Aufruf die BOM)

Die csv-Datei kann mit jedem Tabellenkalkulationsprogramm besichtigt und korrigiert werden.

Aus part-db kann dann der xml-Code und die Edit-Funktion für die Import-Eingabe entfallen.

[weinbauer73]

Ohne mir das angeschaut zu haben, wäre ein Upload der CSV-Datei und ein direkter Import per SQL (falls von der DB unterstützt) sinnvoller. Kann man ja auch in einer temporäre oder eine eigene Import-Tabelle machen, die dann in Part-DB bearbeitet werden kann. Sollte das direkte Importieren nicht gehen, dann wäre ein zeilenweises abarbeiten gut genug. Damit würden wir nicht in das Problem "max_input_vars" rennen. Nur die Laufzeit des Scriptes wäre zu beachten.

Ich werde mal schauen, ob ich die nächsten Tage mir das anschauen kann. Es steht ja eh noch der Umbau von Frame auf Ajax an, den ich letztes Jahr machen wollte. Zeit ist aber das Problem ;-)

[weinbauer73]

So, kurz mal in lib/lib.import.php reingeschaut und das Grausen bekommen. Ansich ist die Idee ja gut, den Inhalt der zu importierenden Datei anzuzeigen, aber ich würde das wie oben über eine temporäre Tabelle machen, bei der nur der Index jeder Zeile per Request an Part-DB geschickt wird. Wenn alle Zeilen in Ordnung sind, reicht sogar ein einziges Flag. Mit Ajax lässt sich auch ein Status für die jeweilige Zeile im Hintergrund setzen, ob die Zeile am Ende übernommen wird. Die Datenmenge ist dabei verschwindet gering.

[ajfre]

Viel sinnvoller, als eine Anzeige/Edit-Funktion für die zu importierenden Daten fände ich eine Miemik, die den Import auch in geschachtelte Kategorien zuläßt. So wie es im Moment ist, geht das nur mit ziemlich unschönen Tricksereien.

[weinbauer73]

Wenn ich den Import neu geschrieben habe, dann können wir ja auch über die geschachtelten Kategorien reden. Im Moment würde ich jede Erweiterung nicht angehen, das verkompliziert alles.